129 lines
8.6 KiB
HTML
129 lines
8.6 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="Manually collecting and refreshing statistics" />
|
||
|
<meta name="abstract" content="You can manually collect and refresh statistics through iSeries Navigator or by using Statistics APIs." />
|
||
|
<meta name="description" content="You can manually collect and refresh statistics through iSeries Navigator or by using Statistics APIs." />
|
||
|
<meta name="DC.subject" content="statistics manager, manually collecting and refreshing statistics" />
|
||
|
<meta name="keywords" content="statistics manager, manually collecting and refreshing statistics" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="statsmanager.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="../rzakz/rzakzqdbfstccol.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="statsmanually" />
|
||
|
<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>Manually collecting and refreshing statistics</title>
|
||
|
</head>
|
||
|
<body id="statsmanually"><a name="statsmanually"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Manually collecting and refreshing statistics</h1>
|
||
|
<div><p>You can manually collect and refresh statistics through iSeries™ Navigator
|
||
|
or by using Statistics APIs.</p>
|
||
|
<div class="section"><p>To collect statistics using iSeries Navigator, right-click a table
|
||
|
or alias and select Statistic Data. On the Statistic Data dialog, click New.
|
||
|
Then select the columns that you want to collect statistics for. Once you
|
||
|
have selected the columns, you can collect the statistics immediately or collect
|
||
|
them in the background. </p>
|
||
|
</div>
|
||
|
<div class="section"><p>To refresh a statistic using iSeries Navigator, right-click a table
|
||
|
or alias and select <span class="uicontrol">Statistic Data</span>. Click <span class="uicontrol">Update</span>.
|
||
|
Select the statistic that you want to refresh. You can collect the statistics
|
||
|
immediately or collect them in the background.</p>
|
||
|
</div>
|
||
|
<div class="section"><p>There are several scenarios in which the manual management (create,
|
||
|
remove, refresh, and so on) of column statistics may be beneficial and recommended.</p>
|
||
|
<dl><dt class="dlterm">High Availability (HA) solutions</dt>
|
||
|
<dd>When considering the design of high availability solutions where data
|
||
|
is replicated to a secondary system by using journal entries, it is important
|
||
|
to know that column statistics information is not journaled. That means that,
|
||
|
on your backup system, no column statistics are available when
|
||
|
you first start using that system. To prevent the "warm up" effect that this
|
||
|
may cause, you may want to propagate the column statistics were gathered on
|
||
|
your production system and recreate them on your backup system manually.</dd>
|
||
|
<dt class="dlterm">ISV (Independent Solution Provider) preparation</dt>
|
||
|
<dd>An ISV may want to deliver a solution to a customer that already includes
|
||
|
column statistics frequently used in the application instead of waiting for
|
||
|
the automatic statistics collection to create them. A way to accomplish this
|
||
|
is to run the application on the development system for some time and examine
|
||
|
which column statistics were created automatically. You can then generate
|
||
|
a script file to be shipped as part of the application that should be executed
|
||
|
on the customer system after the initial data load took place.</dd>
|
||
|
<dt class="dlterm">Business Intelligence environments</dt>
|
||
|
<dd>In a large Business Intelligence environment, it is quite common for large
|
||
|
data load and update operations to occur overnight. As column statistics are
|
||
|
marked as stale only when they are touched by the Statistics Manager, and
|
||
|
then refreshed after first touch, you may want to consider refreshing them
|
||
|
manually after loading the data.<p>You can do this easily by toggling the
|
||
|
system value QDBFSTCCOL to *NONE and then back to *ALL. This causes all stale
|
||
|
column statistics to be refreshed and starts collection of any column statistics
|
||
|
previously requested by the system but not yet available. Since this process
|
||
|
relies on the access plans stored in the Plan Cache, avoid performing a system
|
||
|
initial program load (IPL) before toggling QDBFSTCCOL since an IPL clears
|
||
|
the Plan Cache. </p>
|
||
|
<p>You should be aware that this procedure works only
|
||
|
if you do not delete (drop) the tables and recreate them in the process of
|
||
|
loading your data. When deleting a table, access plans in the Plan Cache that
|
||
|
refer to this table are deleted. Information about column statistics on that
|
||
|
table is also lost. The process in this environment is either to add data
|
||
|
to your tables or to clear the tables instead of deleting them.</p>
|
||
|
</dd>
|
||
|
<dt class="dlterm">Massive data updates</dt>
|
||
|
<dd>Updating rows in a column statistics-enabled table that significantly
|
||
|
change the cardinality, add new ranges of values, or change the distribution
|
||
|
of data values can affect the performance for queries when they are first
|
||
|
run against the new data. This may happen because, on the first run of such
|
||
|
a query, the optimizer uses stale column statistics to make decisions on the
|
||
|
access plan. At that point, it starts a request to refresh the column statistics. <p>If
|
||
|
you know that you are doing this kind of update to your data, you may want
|
||
|
to toggle the system value QDBFSTCCOL to *NONE and back to *ALL or *SYSTEM.
|
||
|
This causes an analysis of the Plan Cache. The analysis includes searching
|
||
|
for column statistics that were used in the generation of an access plan,
|
||
|
analyzing them for staleness, and requesting updates for the stale statistics. </p>
|
||
|
<p>If
|
||
|
you massively update or load data and run queries against these tables at
|
||
|
the same time, then the automatic collection of column statistics tries to
|
||
|
refresh every time 15% of the data is changed. This can be redundant processing
|
||
|
since you are still in the process of updating or loading the data. In this
|
||
|
case, you may want to block automatic statistics collection for the tables
|
||
|
in question and deblock it again after the data update or load finishes. An
|
||
|
alternative is to turn off automatic statistics collection for the whole system
|
||
|
before updating or loading the data and switching it back on after the updating
|
||
|
or loading has finished.</p>
|
||
|
</dd>
|
||
|
<dt class="dlterm">Backup and recovery</dt>
|
||
|
<dd>When thinking about backup and recovery strategies, keep in mind that
|
||
|
creation of column statistics is not journaled. Column statistics that exist
|
||
|
at the time a save operation occurs are saved as part of the table and restored
|
||
|
with the table. Any column statistics created after the save took place are
|
||
|
lost and cannot be recreated by using techniques such as applying journal
|
||
|
entries. If you have a rather long interval between save operations and rely
|
||
|
heavily on journaling for restoring your environment to a current state, consider
|
||
|
keeping track of column statistics that are generated after the latest save
|
||
|
operation.</dd>
|
||
|
</dl>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="statsmanager.htm" title="As stated earlier, the collection of statistics is handled by a separate component called the Statistics Manager. Statistical information can be used by the query optimizer to determine the best access plan for a query. Since the query optimizer bases its choice of access plan on the statistical information found in the table, it is important that this information be current.">Collecting statistics with the Statistics Manager</a></div>
|
||
|
</div>
|
||
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
<div><a href="../rzakz/rzakzqdbfstccol.htm">Allow background database statistics collection (QDBFSTCCOL) system value</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|