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

109 lines
7.8 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="Plan Cache" />
<meta name="abstract" content="The Plan Cache is a repository that contains the access plans for queries that were optimized by SQE." />
<meta name="description" content="The Plan Cache is a repository that contains the access plans for queries that were optimized by SQE." />
<meta name="DC.subject" content="plan cache, definitions, plan cache" />
<meta name="keywords" content="plan cache, definitions, plan cache" />
<meta name="DC.Relation" scheme="URI" content="queryoptimize.htm" />
<meta name="DC.Relation" scheme="URI" content="ipuc.htm" />
<meta name="DC.Relation" scheme="URI" content="cqa.htm" />
<meta name="DC.Relation" scheme="URI" content="rzajqdisplayplancache.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="rzajqcache" />
<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>Plan Cache</title>
</head>
<body id="rzajqcache"><a name="rzajqcache"><!-- --></a>
<img src="./delta.gif" alt="Start of change" /><!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Plan Cache</h1>
<div><p>The Plan Cache is a repository that contains the access plans for
queries that were optimized by SQE.</p>
<p>Access plans generated by CQE are not stored in the Plan Cache; instead,
they are stored in SQL Packages, the system-wide statement cache, and job
cache). The purposes of the Plan Cache are to:</p>
<ul><li>Facilitate the reuse of a query access plan when the same query is re-executed</li>
<li>Store runtime information for subsequent use in future query optimizations</li>
</ul>
<p>Once an access plan is created, it is available for use by all users and
all queries, regardless of where the query originates. Furthermore, when an
access plan is tuned, when creating an index for example, all queries can
benefit from this updated access plan. This eliminates the need to reoptimize
the query, resulting in greater efficiency.</p>
<p>The graphic below shows the concept of reusability of the query access
plans stored in the Plan Cache:</p>
<p><br /><img src="rzajq550.gif" alt="Description of the Plan Cache. Statements are stored from different packages and programs in different plans in the plan cache. If Statement 3 exists in both SQL package 1 and SQL package 2, the plan is stored once in the plan cache." /><br /></p>
<p>As shown above, the Plan Cache is interrogated each time a query is executed
in order to determine if a valid access plan exists that satisfies the requirements
of the query. If a valid access plan is found, it is used to implement the
query. Otherwise a new access plan is created and stored in the Plan Cache
for future use. The Plan Cache is automatically updated with new query access
plans as they are created, or is updated for an existing plan (the next time
the query is run) when new statistics or indexes become available. The Plan
Cache is also automatically updated by the database with runtime information
as the queries are run. It is created with an overall size of 512 Megabytes
(MB). Each plan cache entry contains the original query, the optimized query
access plan and cumulative runtime information gathered during the runs of
the query. In addition, several instances of query runtime objects are stored
with a plan cache entry. These runtime objects are the real executables and
temporary storage containers (hash tables, sorts, temporary indexes, and so
on) used to run the query. All systems are currently configured with the same
size Plan Cache, regardless of the server size or the hardware configuration. </p>
<p>When the Plan Cache exceeds its designated size, a background task is automatically
scheduled to remove plans from the Plan Cache. Access plans are deleted based
upon the age of the access plan, how frequently it is being used and how much
cumulative resources (CPU/IO) were consumed by the runs of the query. The
total number of access plans stored in the Plan Cache depends largely upon
the complexity of the SQL statements that are being executed. In certain test
environments, there have been typically between 10,000 to 20,000 unique access
plans stored in the Plan Cache. The Plan Cache is cleared when a system Initial
Program Load (IPL) is performed.</p>
<p>Multiple access plans can be maintained for a single SQL statement. Although
the SQL statement itself is the primary hash key to the Plan Cache, different
environmental settings can cause different access plans to be stored in the
Plan Cache. Examples of these environmental settings include: </p>
<ul><li>Different SMP Degree settings for the same query</li>
<li>Different library lists specified for the query tables</li>
<li>Different settings for the job's share of available memory in the current
pool</li>
<li>Different ALWCPYDTA settings</li>
</ul>
<p>Currently, the Plan Cache can maintain a maximum of 3 different access
plans for the same SQL statement. As new access plans are created for the
same SQL statement, older access plans are discarded to make room for the
new access plans. There are, however, certain conditions that can cause an
existing access plan to be invalidated. Examples of these include: </p>
<ul><li>Specifying REOPTIMIZE_ACCESS_PLAN(*YES) or (*FORCE) in the QAQQINI table
or in Run SQL Scripts</li>
<li>Deleting or recreating the table that the access plan refers to</li>
<li>Deleting an index that is used by the access plan</li>
</ul>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="queryoptimize.htm" title="DB2 UDB for iSeries provides two query engines to process queries: the Classic Query Engine (CQE) and the SQL Query Engine (SQE).">Query Engine Overview</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="ipuc.htm" title="Some complex queries can perform better by using a sort or hashing method to evaluate the query instead of using or creating an index.">Effects of the ALWCPYDTA parameter on database performance</a></div>
<div><a href="cqa.htm" title="You can modify different types of attributes of the queries that you will execute during a certain job with the Change Query Attributes (CHGQRYA) CL command, or by using the iSeries Navigator Change Query Attributes interface.">Change the attributes of your queries with the Change Query Attributes (CHGQRYA) command</a></div>
<div><a href="rzajqdisplayplancache.htm" title="The Plan Cache contains a wealth of information about the SQE queries being run through the database. Its contents are viewable through the iSeries Navigator GUI interface.">Viewing the plan cache with iSeries Navigator</a></div>
</div>
</div>
<img src="./deltaend.gif" alt="End of change" /></body>
</html>