98 lines
7.1 KiB
HTML
98 lines
7.1 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="Effects of the ALWCPYDTA parameter on database performance" />
|
||
|
<meta name="abstract" content="Some complex queries can perform better by using a sort or hashing method to evaluate the query instead of using or creating an index." />
|
||
|
<meta name="description" content="Some complex queries can perform better by using a sort or hashing method to evaluate the query instead of using or creating an index." />
|
||
|
<meta name="DC.subject" content="improving performance, using, a copy of the data, allow copy data (ALWCPYDTA), performance improvement, using copy of the data, copy of the data, using to improve performance, parameters, command, ALWCPYDTA (allow copy data)" />
|
||
|
<meta name="keywords" content="improving performance, using, a copy of the data, allow copy data (ALWCPYDTA), performance improvement, using copy of the data, copy of the data, using to improve performance, parameters, command, ALWCPYDTA (allow copy data)" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="genconsid.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzajqcache.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="precompileopts.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzajqrindscan.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzajqrinprobe.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="ipuc" />
|
||
|
<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>Effects of the ALWCPYDTA parameter on database performance</title>
|
||
|
</head>
|
||
|
<body id="ipuc"><a name="ipuc"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Effects of the ALWCPYDTA parameter on database performance</h1>
|
||
|
<div><p>Some complex queries can perform better by using a sort or hashing
|
||
|
method to evaluate the query instead of using or creating an index. </p>
|
||
|
<div class="section"><p>By using the sort or hash, the database manager is able to separate
|
||
|
the row selection from the ordering and grouping process. Bitmap processing
|
||
|
can also be partially controlled through this parameter. This separation allows
|
||
|
the use of the most efficient index for the selection. For example, consider
|
||
|
the following SQL statement: </p>
|
||
|
<pre>EXEC SQL
|
||
|
<strong>DECLARE</strong> C1 <strong>CURSOR FOR</strong>
|
||
|
<strong>SELECT</strong> EMPNO, LASTNAME, WORKDEPT
|
||
|
<strong>FROM</strong> CORPDATA.EMPLOYEE
|
||
|
<strong>WHERE</strong> WORKDEPT = 'A00'
|
||
|
<strong>ORDER BY</strong> LASTNAME
|
||
|
END-EXEC.</pre>
|
||
|
</div>
|
||
|
<div class="section"><p>The above SQL statement can be written in the following way by
|
||
|
using the OPNQRYF command: </p>
|
||
|
<pre>OPNQRYF FILE(CORPDATA/EMPLOYEE)
|
||
|
FORMAT(FORMAT1)
|
||
|
QRYSLT(WORKDEPT *EQ ''AOO'')
|
||
|
KEYFLD(LASTNAME)</pre>
|
||
|
</div>
|
||
|
<div class="section"><p>In the above example when ALWCPYDTA(*NO) or ALWCPYDTA(*YES) is
|
||
|
specified, the database manager may try to create an index from the first
|
||
|
index with a column named LASTNAME, if such an index exists. The rows in the
|
||
|
table are scanned, using the index, to select only the rows matching the WHERE
|
||
|
condition.</p>
|
||
|
</div>
|
||
|
<div class="section"><p>If ALWCPYDTA(*OPTIMIZE) is specified, the database manager uses
|
||
|
an index with the first index column of WORKDEPT. It then makes a copy of
|
||
|
all of the rows that match the WHERE condition. Finally, it may sort the copied
|
||
|
rows by the values in LASTNAME. This row selection processing is significantly
|
||
|
more efficient, because the index used immediately locates the rows to be
|
||
|
selected.</p>
|
||
|
</div>
|
||
|
<div class="section"><p>ALWCPYDTA(*OPTIMIZE) optimizes the total time that
|
||
|
is required to process the query. However, the time required to receive the
|
||
|
first row may be increased because a copy of the data must be made before
|
||
|
returning the first row of the result table. This initial change in response
|
||
|
time may be important for applications that are presenting interactive displays
|
||
|
or that retrieve only the first few rows of the query. The <span class="keyword">DB2 Universal Database™ for iSeries™</span> query
|
||
|
optimizer can be influenced to avoid sorting by using the OPTIMIZE clause.</p>
|
||
|
</div>
|
||
|
<div class="section"><p>Queries that involve a join operation may also benefit from ALWCPYDTA(*OPTIMIZE)
|
||
|
because the join order can be optimized regardless of the ORDER BY specification.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="genconsid.htm" title="As you code your applications, there are some general tips that can help you optimize performance.">General DB2 UDB for iSeries performance considerations</a></div>
|
||
|
</div>
|
||
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
<div><a href="rzajqcache.htm" title="The Plan Cache is a repository that contains the access plans for queries that were optimized by SQE.">Plan Cache</a></div>
|
||
|
</div>
|
||
|
<div class="relref"><strong>Related reference</strong><br />
|
||
|
<div><a href="precompileopts.htm" title="Several precompile options are available for creating SQL programs with improved performance. They are only options because using them may impact the function of the application. For this reason, the default value for these parameters is the value that will ensure successful migration of applications from prior releases. However, you can improve performance by specifying other options.">Effects of precompile options on database performance</a></div>
|
||
|
<div><a href="rzajqrindscan.htm" title="A radix index scan operation is used to retrieve the rows from a table in a keyed sequence. Like a Table Scan, all of the rows in the index will be sequentially processed, but the resulting row numbers will be sequenced based upon the key columns.">Radix index scan</a></div>
|
||
|
<div><a href="rzajqrinprobe.htm" title="A radix index probe operation is used to retrieve the rows from a table in a keyed sequence. The main difference between the Radix Index Probe and the Radix Index Scan is that the rows being returned must first be identified by a probe operation to subset the rows being retrieved.">Radix index probe</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|