ibm-information-center/dist/eclipse/plugins/i5OS.ic.ddp_5.4.0.1/rbal1genop.htm

123 lines
7.4 KiB
HTML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="reference" />
<meta name="DC.Title" content="General operations for a distributed relational database" />
<meta name="abstract" content="To plan for the general operation of a distributed relational database, consider both performance and availability." />
<meta name="description" content="To plan for the general operation of a distributed relational database, consider both performance and availability." />
<meta name="DC.subject" content="operations, general, planning for, planning, general operations, stored procedure" />
<meta name="keywords" content="operations, general, planning for, planning, general operations, stored procedure" />
<meta name="DC.Relation" scheme="URI" content="rbal1managestrat.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rbal1genop" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>General operations for a distributed relational database</title>
</head>
<body id="rbal1genop"><a name="rbal1genop"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">General operations for a distributed relational database</h1>
<div><p>To plan for the general operation of a distributed relational database,
consider both performance and availability.</p>
<div class="section"><p>The following design considerations can help you improve both
the performance and availability of a distributed relational database:</p>
</div>
<div class="section"><ul><li>If an application involves transactions that run frequently or that send
or receive a lot of data, you should try to keep it in the same location as
the data.</li>
<li>For data that needs to be shared by applications in different locations,
put the data in the location with the most activity.</li>
<li>If the applications in one location need the data as much as the applications
in another location, consider keeping copies of the data at both locations.
When keeping copies at multiple locations, ask yourself the following questions
about your management strategy: <ul><li>Will users be allowed to make updates to the copies?</li>
<li>How and when will the copies be refreshed with current data?</li>
<li>Will all copies have to be backed up or will backing up one copy be sufficient?</li>
<li>How will general administration activities be performed consistently for
all copies?</li>
<li>When is it permissible to delete one of the copies?</li>
</ul>
</li>
<li>Consider whether the distributed databases will be administered from a
central location or from each database location.</li>
</ul>
</div>
<div class="section"><p>You can also improve performance by doing the following things:</p>
<ul><li>If data and applications must be kept at different locations, do the following
things to keep the performance within acceptable limits: <ul><li>Keep data traffic across the network as low as possible by only retrieving
the data columns that will be used by the application; that is, avoid using
* in place of a list of column names as part of a SELECT statement.</li>
<li>Discourage programmers from coding statements that send large amounts
of data to or receive large amounts of data from a remote location; that is,
encourage the use of the WHERE clause of the SELECT statement to limit the
number of rows of data.</li>
<li>Use referential integrity, triggers, and stored procedures (an SQL CALL
statement after a CONNECT to a remote relational database management system);
this improves performance by distributing processing to the application server
(AS), which can substantially reduce line traffic.</li>
<li>Use read-only queries where appropriate by specifying the FOR FETCH ONLY
clause.</li>
<li>Be aware of rules for blocking of queries. For example, in <span class="keyword">iSeries™</span>-to-<span class="keyword">iSeries</span> queries, blocking of read-only
data is done only for COMMIT(*NONE), or for COMMIT(*CHG) and COMMIT(*CS) when
ALWBLK(*ALLREAD) is specified.</li>
<li>Keep the number of accesses to remote data low by using local data in
place of remote data whenever possible.</li>
<li>Use SQL set operations to process multiple rows at the application requester
with a single SQL request.</li>
<li>Try to avoid dropping of connections by using DDMCNV(*KEEP) when running
with remote unit of work (RUW) connection management, or by running with distributed
unit of work (DUW) connection management.</li>
</ul>
</li>
<li>Provide sufficient network capacity by doing the following things:<ul><li>Increase the capacity of the network by installing high-speed, high-bandwidth
lines or by adding lines at appropriate points in the network.</li>
<li>Reduce the contention or improve the contention balance on certain processors.
For example, move existing applications from a host server to a departmental
server or group some distributed relational database work into batch.</li>
</ul>
</li>
<li>Encourage good table design. At the distributed relational database locations,
encourage appropriate use of primary keys, table indexes, and normalization
techniques.</li>
<li>Ensure data types of host variables used in WHERE clauses are consistent
with the data types of the associated key column data types. For example,
a floating-point host variable has been known to disqualify the use of an
index built over a column of a different data type.</li>
</ul>
</div>
<div class="section"><p>You can also improve availability by doing the following
things:</p>
<ul><li>In general, try to limit the amount of data traffic across the network.</li>
<li>If data and applications must be kept at different locations, do the following
things to keep the availability within acceptable limits: <ul><li>Establish alternate network routes.</li>
<li>Consider the effect of time zone differences on availability: <ul><li>Will qualified people be available to bring up the server?</li>
<li>Will off-hours batch work interfere with processing?</li>
</ul>
</li>
<li>Ensure good backup and recovery features.</li>
<li>Ensure people are skilled in backup and recovery.</li>
</ul>
</li>
</ul>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbal1managestrat.htm" title="When you are managing a distributed relational database, keep these strategies in mind.">Develop a management strategy for a distributed relational database</a></div>
</div>
</div>
</body>
</html>