153 lines
10 KiB
HTML
153 lines
10 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="concept" />
|
||
|
|
<meta name="DC.Title" content="Open Query File (OPNQRYF) command: Performance considerations" />
|
||
|
|
<meta name="abstract" content="Here are tips and techniques for optimizing the performance when you use the Open Query File (OPNQRYF) command." />
|
||
|
|
<meta name="description" content="Here are tips and techniques for optimizing the performance when you use the Open Query File (OPNQRYF) command." />
|
||
|
|
<meta name="DC.subject" content="performance, considerations, general, improving, with OPNQRYF command and keyed sequence access path" />
|
||
|
|
<meta name="keywords" content="performance, considerations, general, improving, with OPNQRYF command and keyed sequence access path" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rbafoopnqf.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzajq/rzajqkickoff.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="rbafoqryprf" />
|
||
|
|
<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>Open Query File (OPNQRYF) command: Performance considerations</title>
|
||
|
|
</head>
|
||
|
|
<body id="rbafoqryprf"><a name="rbafoqryprf"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Open Query File (OPNQRYF) command: Performance considerations</h1>
|
||
|
|
<div><p>Here are tips and techniques for optimizing the performance
|
||
|
|
when you use the Open Query File (OPNQRYF) command.</p>
|
||
|
|
<p>The best performance can occur when the OPNQRYF command uses an existing
|
||
|
|
keyed sequence access path. For example, if you want to select all the records
|
||
|
|
where the <em>Code</em> field is equal to B and an access path exists over the <em>Code</em> field,
|
||
|
|
the system can use the access path to perform the selection (key positioning
|
||
|
|
selection) rather than read the records and select at run time (dynamic selection).</p>
|
||
|
|
<div class="p">The OPNQRYF command cannot use an existing index when any of the following
|
||
|
|
conditions are true: <ul><li>The key field in the access path is derived from a substring function.</li>
|
||
|
|
<li>The key field in the access path is derived from a concatenation function.</li>
|
||
|
|
<li>Both listed here are true of the sort sequence table associated with the
|
||
|
|
query (specified on the SRTSEQ parameter): <ul><li>It is a shared-weight sequence table.</li>
|
||
|
|
<li>It does not match the sequence table associated with the access path (a
|
||
|
|
sort sequence table or an alternate collating sequence table).</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>Both listed here are true of the sort sequence table associated with the
|
||
|
|
query (specified on the SRTSEQ parameter): <ul><li>It is a unique-weight sequence table.</li>
|
||
|
|
<li>It does not match the sequence table associated with the access path (a
|
||
|
|
sort sequence table or an alternate collating sequence table) when either: <ul><li>Ordering is specified (KEYFLD parameter).</li>
|
||
|
|
<li>Record selection exists (QRYSLT parameter) that does not use *EQ, *NE,
|
||
|
|
*CT, %WLDCRD, or %VALUES.</li>
|
||
|
|
<li>Join selection exists (JFLD parameter) that does not use *EQ or *NE operators.</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p>Part of the OPNQRYF processing is to determine what is the fastest approach
|
||
|
|
to satisfying your request. If the file you are using is large and most of
|
||
|
|
the records have the <em>Code</em> field equal to B, it is faster to use arrival
|
||
|
|
sequence processing than to use an existing keyed sequence access path. Your
|
||
|
|
program still sees the same records. The OPNQRYF processing can only make
|
||
|
|
this type of decision if an access path exists on the <em>Code</em> field. In
|
||
|
|
general, if your request includes approximately 20% or more of the number
|
||
|
|
of records in the file, the OPNQRYF processing tends to ignore the existing
|
||
|
|
access paths and read the file in arrival sequence.</p>
|
||
|
|
<p>If no access path exists over the <em>Code</em> field, the program reads
|
||
|
|
all of the records in the file and passes only the selected records to your
|
||
|
|
program. That is, the file is processed in arrival sequence.</p>
|
||
|
|
<p>The system can perform selection faster than your application program.
|
||
|
|
If no appropriate keyed sequence access path exists, either your program or
|
||
|
|
the system makes the selection of the records you want to process. Allowing
|
||
|
|
the system to perform the selection process is considerably faster than passing
|
||
|
|
all the records to your application program.</p>
|
||
|
|
<p>This is especially true if you are opening a file for update operations
|
||
|
|
because individual records must be passed to your program, and locks are placed
|
||
|
|
on every record read (in case your program needs to update the record). By
|
||
|
|
letting the system perform the record selection, the only records passed to
|
||
|
|
your program and locked are those that meet your selection values.</p>
|
||
|
|
<p>If you use the KEYFLD parameter to request a specific sequence for reading
|
||
|
|
records, the fastest performance results if an access path already exists
|
||
|
|
that uses the same key specification or if a keyed sequence access path exists
|
||
|
|
that is similar to your specifications (such as a key that contains all the
|
||
|
|
fields you specified plus some additional fields on the end of the key). This
|
||
|
|
is also true for the GRPFLD parameter and on the to-fields of the JFLD parameter.
|
||
|
|
If no such access path exists, the system builds an access path and maintains
|
||
|
|
it as long as the file is open in your job.</p>
|
||
|
|
<p>Processing all the records in a file by an access path that does not already
|
||
|
|
exist is generally not as efficient as using a full record sort, if the number
|
||
|
|
of records to be arranged (not necessarily the total number of records in
|
||
|
|
the file) exceeds 1000 and is greater than 20% of the records in the file.
|
||
|
|
While it is generally faster to build the keyed sequence access path than
|
||
|
|
to do the sort, faster processing allowed by the use of arrival sequence processing
|
||
|
|
normally favors sorting the data when looking at the total job time. If a
|
||
|
|
usable access path already exists, using the access path can be faster than
|
||
|
|
sorting the data. You can use the ALWCPYDTA(*OPTIMIZE) parameter of the Open
|
||
|
|
Query File (OPNQRYF) command to allow the system to use a full record sort
|
||
|
|
if this is the fastest method of processing records.</p>
|
||
|
|
<p>If you do not intend to read all of the query records and if the OPTIMIZE
|
||
|
|
parameter is *FIRSTIO or *MINWAIT, you can specify a number to indicate how
|
||
|
|
many records you intend to retrieve. If the number of records is considerably
|
||
|
|
less than the total number the query is expected to return, the system might
|
||
|
|
select a faster access method.</p>
|
||
|
|
<p>If you use the grouping function, faster performance is achieved if you
|
||
|
|
specify selection before grouping (QRYSLT parameter) instead of selection
|
||
|
|
after grouping (GRPSLT parameter). Only use the GRPSLT parameter for comparisons
|
||
|
|
involving aggregate functions.</p>
|
||
|
|
<div class="p">For most uses of the OPNQRYF command, new or existing access paths are
|
||
|
|
used to access the data and present it to your program. In some cases of the
|
||
|
|
OPNQRYF command, the system must create a temporary file. The rules for when
|
||
|
|
a temporary file is created are complex, but the following cases are typical
|
||
|
|
in which this occurs: <ul><li>When you specify a dynamic join, and the KEYFLD parameter describes key
|
||
|
|
fields from different physical files.</li>
|
||
|
|
<li>When you specify a dynamic join and the GRPFLD parameter describes fields
|
||
|
|
from different physical files.</li>
|
||
|
|
<li>When you specify both the GRPFLD and KEYFLD parameters but they are not
|
||
|
|
the same.</li>
|
||
|
|
<li>When the fields specified on the KEYFLD parameter total more than 2000
|
||
|
|
bytes in length.</li>
|
||
|
|
<li>When you specify a dynamic join and *MINWAIT for the OPTIMIZE parameter.</li>
|
||
|
|
<li>When you specify a dynamic join using a join logical file and the join
|
||
|
|
type (JDFTVAL) of the join logical file does not match the join type of the
|
||
|
|
dynamic join.</li>
|
||
|
|
<li>When you specify a logical file and the format for the logical file refers
|
||
|
|
to more than one physical file.</li>
|
||
|
|
<li>When you specify an SQL view, the system might require a temporary file
|
||
|
|
to contain the results of the view.</li>
|
||
|
|
<li>When the ALWCPYDTA(*OPTIMIZE) parameter is specified and using a temporary
|
||
|
|
result would improve the performance of the query.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p>When a dynamic join occurs (JDFTVAL(*NO)), the OPNQRYF command attempts
|
||
|
|
to improve performance by reordering the files and joining the file with the
|
||
|
|
smallest number of selected records to the file with the largest number of
|
||
|
|
selected records. To prevent the OPNQRYF command from reordering the files,
|
||
|
|
specify JORDER(*FILE). This forces the OPNQRYF command to join the files in
|
||
|
|
the order specified on the FILE parameter.</p>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbafoopnqf.htm" title="The Open Query File (OPNQRYF) command is a control language (CL) command that allows you to perform many data processing functions on database files. These topics discuss how to create a query using the OPNQRYF command, how to specify parameters for its major functions, and how to use it with your high-level language program.">Use Open Query File (OPNQRYF) command</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="../rzajq/rzajqkickoff.htm">Database performance and query optimization</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|