ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzajq_5.4.0.1/rzajqmon3.htm

134 lines
9.0 KiB
HTML
Raw Permalink Normal View History

2024-04-02 14:02:31 +00:00
<?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="Database monitor performance analysis example 3" />
<meta name="abstract" content="Your next step may include further analysis of the table scan data. The previous examples contained a column titled Index Advised. A 'Y' (yes) in this column is a hint from the query optimizer that the query may perform better with an index to access the data. For the queries where an index is advised, notice that the rows selected by the query are low in comparison to the total number of rows in the table. This is another indication that a table scan may not be optimal. Finally, a long execution time may highlight queries that may be improved by performance tuning." />
<meta name="description" content="Your next step may include further analysis of the table scan data. The previous examples contained a column titled Index Advised. A 'Y' (yes) in this column is a hint from the query optimizer that the query may perform better with an index to access the data. For the queries where an index is advised, notice that the rows selected by the query are low in comparison to the total number of rows in the table. This is another indication that a table scan may not be optimal. Finally, a long execution time may highlight queries that may be improved by performance tuning." />
<meta name="DC.subject" content="performance analysis, example 3, examples" />
<meta name="keywords" content="performance analysis, example 3, examples" />
<meta name="DC.Relation" scheme="URI" content="dbmonexamples.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="rzajqmon3" />
<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>Database monitor performance analysis example 3</title>
</head>
<body id="rzajqmon3"><a name="rzajqmon3"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Database monitor performance analysis example 3</h1>
<div><p>Your next step may include further analysis of the table scan data.
The previous examples contained a column titled Index Advised. A 'Y' (yes)
in this column is a hint from the query optimizer that the query may perform
better with an index to access the data. For the queries where an index is
advised, notice that the rows selected by the query are low in comparison
to the total number of rows in the table. This is another indication that
a table scan may not be optimal. Finally, a long execution time may highlight
queries that may be improved by performance tuning.</p>
<div class="section"><p>The next logical step is to look into the index advised optimizer
hint. The following query can be used for this: </p>
<pre><strong>SELECT</strong> A.System_Table_Schema, A.System_Table_Name,
A.Index_Advised, A.Index_Advised_Columns,
A.Index_Advised_Columns_Count, B.Open_Id,
C.Statement_Text_Long
<strong>FROM</strong> LIB/QQQ3000 A <strong>INNER JOIN</strong> LIB/QQQ3014 B
<strong>ON</strong> (A.Join_Column = B.Join_Column <strong>AND</strong>
A.Unique_Count = B.Unique_Count)
<strong>LEFT OUTER JOIN</strong> LIB/QQQ1000 C
<strong>ON</strong> (A.Join_Column = C.Join_Column <strong>AND</strong>
A.Unique_Count = C.Unique_Count)
<strong>WHERE</strong> A.Index_Advised = 'Y'</pre>
<p>There are two slight modifications
from the first example. First, the selected columns have been changed. Most
important is the selection of column Index_Advised_Columns that contains
a list of possible key columns to use when creating the index suggested by
the query optimizer. Second, the query selection limits the output to those
table scan queries where the optimizer advises that an index be created (A.Index_Advised
= 'Y'). The table below shows what the results might look like.</p>
</div>
<table cellpadding="4" cellspacing="0" border="1" class="tableborder"><tr><td>
<a name="rzajqmon3__inxadv"><!-- --></a><table cellpadding="4" cellspacing="0" summary="" id="rzajqmon3__inxadv" width="100%" border="0"><caption>Table 1. Output with Recommended
Key Columns</caption><thead align="left"><tr><th align="left" valign="bottom" width="10%" id="d0e67">Lib Name</th>
<th align="left" valign="bottom" width="10%" id="d0e69">Table Name</th>
<th align="left" valign="bottom" width="10%" id="d0e71">Index Advised</th>
<th align="left" valign="bottom" width="10%" id="d0e73">Advised Key columns</th>
<th align="left" valign="bottom" width="10%" id="d0e75">Advised Primary Key</th>
<th align="left" valign="bottom" width="10%" id="d0e77">Query OPNID</th>
<th align="left" valign="bottom" width="40%" id="d0e79">Statement Text</th>
</tr>
</thead>
<tbody><tr><td align="left" valign="top" width="10%" headers="d0e67 "><strong>LIB1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e69 "><strong>TBL1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e71 "><strong>Y</strong></td>
<td align="left" valign="top" width="10%" headers="d0e73 "><strong>FLD1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e75 "><strong>1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e77 ">&nbsp;</td>
<td align="left" valign="top" width="40%" headers="d0e79 "><pre>SELECT * FROM LIB1/TBL1
WHERE FLD1 = 'A'</pre>
</td>
</tr>
<tr><td align="left" valign="top" width="10%" headers="d0e67 "><strong>LIB1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e69 "><strong>TBL1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e71 "><strong>Y</strong></td>
<td align="left" valign="top" width="10%" headers="d0e73 "><strong>FLD1, FLD2</strong></td>
<td align="left" valign="top" width="10%" headers="d0e75 "><strong>1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e77 ">&nbsp;</td>
<td align="left" valign="top" width="40%" headers="d0e79 "><pre>SELECT * FROM LIB1/TBL1
WHERE FLD1 = 'B' AND
FLD2 &gt; 9000</pre>
</td>
</tr>
<tr><td align="left" valign="top" width="10%" headers="d0e67 "><strong>LIB1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e69 "><strong>TBL4</strong></td>
<td align="left" valign="top" width="10%" headers="d0e71 "><strong>Y</strong></td>
<td align="left" valign="top" width="10%" headers="d0e73 "><strong>FLD1, FLD4</strong></td>
<td align="left" valign="top" width="10%" headers="d0e75 "><strong>1</strong></td>
<td align="left" valign="top" width="10%" headers="d0e77 "><strong>QRY04</strong></td>
<td align="left" valign="top" width="40%" headers="d0e79 ">&nbsp;</td>
</tr>
</tbody>
</table>
</td></tr></table>
<div class="section"><p>At this point you should determine whether it makes sense to create
a permanent index as advised by the optimizer. In this example, creating one
index over LIB1/TBL1 satisfies all three queries since each use a primary
or left-most key column of FLD1. By creating one index over LIB1/TBL1 with
key columns FLD1, FLD2, there is potential to improve the performance of the
second query even more. The frequency these queries are run and the overhead
of maintaining an additional index over the table should be considered when
deciding whether to create the suggested index.</p>
</div>
<div class="section"><p>If you create a permanent index over FLD1, FLD2 the next sequence
of steps is as follows:</p>
</div>
<div class="section"> <ol><li>Start the performance monitor again</li>
<li>Re-run the application</li>
<li>End the performance monitor</li>
<li>Re-evaluate the data.</li>
</ol>
</div>
<div class="section"><p>It is likely that the three index-advised queries are no longer
performing table scans.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="dbmonexamples.htm" title="The iSeries navigator interface provides a powerful tool for gathering and analyzing performance monitor data using database monitor. However, you may want to do your own analysis of the database monitor files.">Database monitor examples</a></div>
</div>
</div>
</body>
</html>