DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

► Timestamp: 2004-11-15 13:44:36.771989 (RUNSTATS)
► Explain time: 2004-11-19 14:56:24:34
If we click the Index node (5) DSNPPH01, the information about the index used to access
SYSPLAN pops up: Fullkeycard of 61 and cluster ratio of 0.4918. The attribute side shows the
number of leaf pages, number of levels, if the rows are clustered for this index, if the index is
padded, and other information.
The index scan node (4) shows the number of input RIDs and output RIDs, scanned leaf
pages, total filter factor, and number of matching columns for this scan.
The fetch node shows a cardinality of 14. This is very interesting. The attribute of the fetch
node shows:
► Scanned rows: 61
► Stage 1 predicate: PL. PLENTRIES=0. Filter factor: 0.459
► Stage 1 returned rows: 28. If we calculate 61 * 0.459 = 27.999
► Stage 2 predicate: NOT EXISTS(SELECT 1 FROM SYSDBRM WHERE
SYSDBRM.PLNAME=PL.NAME); Filter factor: 0.5.
► Stage 2 returned rows: 14
For each entry in the index DSNPPH01 leaf page (no matching index scan) DB2 has to go to
the data portion to verify the predicate PL.PLENTRIES=0. PLENTRIES is the number of
package list entries for the plan. The size of the row in SYSPLAN is 3613 bytes in a 4 KB
page.
Since this query is a correlated subquery, for each row in the outer table the inner query is
re-executed. This subquery is an non-matching index-only scan, resulting in many scans to all
leaf pages in the index PMSYSDBRM1 because the PLNAME is the second column of the
index.
So the largest impact comes from the time to scan all leaf pages for the entries in the index for
the table SYSDBRM. If the number of DBRMs is small, this can be a few pages, but if the
catalog has a large number of DBRMs, for example, 20,000, and the index on columns
PLCREATOR, PLNAME, has a key of 16 bytes, resulting in approximately 200 keys per page,
there is a total of 100 leaf pages for each plan that has PLENTRIES=0.
If there are 10,000 plans not using a package list, there are 10,000 scans of 100 pages.
In this example we executed the query under Visual Explain and the output resulted in two
rows.
Let us take a look at the new Query 3, listed in Table 3-12.
Table 3-12 Consistency Query 31 New
The new Query
SELECT NAME FROM SYSIBM.SYSPLAN
WHERE PLENTRIES = 0
AND NAME NOT IN
(SELECT PLNAME FROM SYSIBM.SYSDBRM);
The new query is a non-correlated query. In a non-correlated subquery case the subquery is
executed only once and the result of the query is materialized in the work file. The validation
of the clause NOT IN is made in the sorted work file.
The optimizer uses the process (scan, sort, work file) to make the performance better as
shown in Figure 3-48. This change makes a nice difference when we compare the CPU cost
Chapter 3. SQL performance 115