1. Rev Up Your SQL Application with Enhanced Statistics!
You may have heard that Enhanced Statistics were added to DB2 for z/OS with DB2 9, and you probably wondered what they are and how they can help. This presentation will answer your questions about what the statistics are, how they are enabled, how they get collected, and what effect they will have on your SQL execution.
Disclaimer: I do not work for IBM, and the conclusions in this document are resolved from research done by my colleagues and myself. There is no guarantee of the correctness of any statement in this presentation, although I have done as much as I can to verify my conclusions.
Ken McDonald, BMC Software
December, 2011
(written by Jim Dee)

2. What Does “Enhanced” Mean?
From dictionary.com:
en·hance [en-hans, -hahns]
–verb (used with object),-hanced, -hanc·ing.
1. to raise to a higher degree; intensify; magnify: The candelight enhanced her beauty.
2. to raise the value or price of: Rarity enhances the worth of old coins.
These definitions from dictionary.com actually fit the bill quite well. We will see that the changes made to the index statistics extracted raise the value of them by providing more information to the DB2 optimizer and generally, improving the performance of SQL that accesses indexes.
Lets start by reviewing what the enhanced statistics include.

3. Introduction Changes made to optimizer statistics in DB2 9
Columns in SYSINDEX - CLUSTERRATIOF and DATAREPEATFACTORF
Enhancing these index statistics is optional
Point is to improve performance of key range extractions in SQL
No help for single row retrievals
“Enhanced statistics” refers to changes made as part of DB2 9. The meaning of the CLUSTERRATIO and CLUSTERRATIOF columns has changed, and in addition, a new column, DATAREPEATFACTORF, has been added. All these changes apply to the SYSIBM.SYSINDEXES table.
These changes are optional, and can be enabled by setting the DSNZPARM value STATCLUS, to ENHANCED instead of STANDARD (the default). When STATCLUS is set to ENHANCED, the RUNSTATS utility operates differently when extracting index statistics, and the optimizer interprets DATAREPEATFACTORF in addition to CLUSTERRATIOF.
The purpose of these values is to provide information to the SQL optimizer to improve the performance of key range extractions from the index, like “…WHERE CUST_ID > …”. Single unique key extractions, like “…WHERE CUST_ID = …” are not affected. We will talk in much more detail about these implications later.
All three of these columns in SYSIBM.SYSINDEXES are updatable by user SQL.

4. DB2 Index Structure Root page Nonleaf Pages Leaf Pages Table Pages
Lets review index structure in DB2 for z/OS. Each page has many entries, arranged logically in ascending key order. So the entire index presents data in order by the key.
The root page entries point to nonleaf pages, nonleaf page entries point to lower level nonleaf pages or to leaf pages, and leaf page entries point to rows in the tablespace (via the RID – row id). For a nonunique index, the rids within one key entry are in ascending sequence.
Although the leaf page entries are in order by key value, they are not necessarily in order by rid and therefore not in tablespace page order. Because there are several rows in a table page, more than one index leaf entry can point to the same table page. Remember that each rid is composed of a tablespace page number and an id within the page. For the rest of this presentation, we will consider rids as tablespace page references.
Lets look a little more closely at how the index data relates to the rows in the tablespace.
Leaf Pages
Table Pages

5. Clustered Retrieval Root page Nonleaf Pages Leaf Pages Table Pages
This slide diagrams clustered retrieval from an index. DB2 is processing a SQL statement which requests retrieval of table rows based upon a range of key values from the clustering index. This diagram shows what would happen if this request were processed immediately after a REORG of the tablespace. The index entries accessed, shown in green, are found in ascending key sequence. In this case, the rids found in the index entries are in ascending order, and consecutive, so the pages retrieved from the tablespace are in ascending sequence and consecutive also. Not only that, within each page, the rows are retrieved in order.
This is the most efficient possible retrieval from the tablespace, in terms of I/O and CPU. DB2 can read the data before it is referenced, so the asynchronous I/O does not hold up data manipulation, and the elapsed time to process the SQL statement is as low as possible. In addition, reading a sequential list of pages is the cheapest way to perform the I/O. This is known as list prefetch.
One of the goals of the optimizer is to detect this situation and select list prefetch to take advantage of it. CLUSTERRATIO is the primary index statistic used by the optimizer to make this choice. If CLUSTERRATIO is high enough (as in our example on this slide), the optimizer will elect not to sort the rids in page order before retrieving from the tablespace, which saves more time.
The number of pages read ahead varies with page size and size of the buffer pool. For buffer pools from 4M to 160MB, the prefetch amount is 128K.
Leaf Pages
Table Pages

6. Not So Clustered Retrieval
Root page
Nonleaf Pages
This slide diagrams a less desirable retrieval from an index. The first part of the diagram, the range retrieval from the index, works in the same way as in the previous diagram. However, in this case, the rids in the index are not in order and they do not refer to consecutive tablespace pages.
This is much less efficient than the table access shown in the previous slide. The I/O to read the tablespace is random (from the point of view of page numbers) and will be synchronous. A lower value for CLUSTERRATIO is how this situation is reflected in index statistics; this allows the optimizer to consider alternative access paths and to value list prefetch lower than in the preceding situation.
Leaf Pages
Table Pages

7. More Clustering Examples
4C0135 4C0039 4BE811 4BE80D 4BE704 4BE021
…page numbers descending
4C0134 4C0135 4C0011 4C040D 4BFF04 4C0021
…up and down in a narrow range
4C0133 … 4C180E4C2A0D
… 4C4804 4C6121 …
…gradual drift in one direction
Slide 5, which showed an example of clustering, did not show all the patterns of tablespace page numbers for which sequential I/O would be desirable. This slide shows three more cases that the CLUSTERRATIO calculation should allow for. In each example, the list of rids from a hypothetical index page is shown, with tablespace page numbers shown in red. For clarity, leading zeros in the rid values are not shown. All these assume 4K tablespace pages, so the prefetch amount would be 32 pages (X‘20’ in hex).
The list on the right shows descending page numbers, within a range of values that is smaller than the prefetch amount. In cases like this, dynamic prefetch is triggered during execution; a sequential pattern is detected, and asynchronous I/O occurs.
The list in the middle shows a pattern in which the page number sometimes goes up and sometimes goes down, but again within a range smaller than the prefetch amount. Again, list prefetch or dynamic prefetch can be selected.
The list on the right shows page numbers within a wider range (X’60’ or 96 pages), but the change is gradual (the dots indicate several more rids between the values above and below the dots). The difference between any two consecutive page numbers never exceeds the prefetch amount.
A significant difference between list prefetch and dynamic prefetch is that list prefetch is chosen by the optimizer and included in the access plan, whereas dynamic prefetch is chosen during execution. The optimizer can choose an access path counting on the occurrence of dynamic prefetch.

8. What is DATAREPEATFACTORF?
4C0135 4C0039 4C0131 4C010D 4C0004 4C0021
4C0022 4C0001 4C0122 4C0107 4C0123 4C1202
4C0134 4C0235 4BFF11 4C140D 4C0104 4C2021 4C0629 4BEC07 4BF123 4C082F 4C2101 4C3240
This slide shows two hypothetical 4K index pages, with lists of consecutive rids from their key entries. Both are clustered; no two consecutive rids differ by more than the prefetch amount. But the patterns look very different. Each list contains 12 rids, but the list on the left refers to 3 tablespace pages, whereas the one on the right refers to 11 page numbers. It should be clear that row retrieval from the tablespace will be more efficient with the pattern on the left than the pattern on the right. If the patterns continue for larger numbers of rids and pages, less I/O will be necessary on the left. Also, fewer slots will be used in the buffer pool, and the working storage used will be smaller.
DATAREPEATFACTORF was a statistic added to record the density of data referred to by an index, and to provide this information to the optimizer.
12 rids…3 page numbers
12 rids…11 page numbers

9. STATCLUS Line 9 on DSNTIP6 panel (“STATISTICS CLUSTERING”)
“ENHANCED” is default
You can specify STANDARD
STATCLUS in DSN6SPRM macro
Affects RUNSTATS operation, not the optimizer
As I said at the beginning of the presentation, use of the enhanced statistics is optional. It is controlled via the STATCLUS DSNZPARM value. This is available in all modes (CM, ENFM, and NFM) of DB2 9.
At the time of installation of DB2 9, you can specify the value you want on line 9 of the DSNTIP6 panel. “ENHANCED” is the default, but if you want to put off conversion to enhanced statistics, you can choose “STANDARD”.
This value is propagated to the STATCLUS parameter in the DSN6SPRM macro.
A STATCLUS value of ENHANCED causes RUNSTATS to calculate CLUSTERRATIO differently, and to calculate a value for DATAREPEATFACTORF. We will examine the details of these calculations shortly.

10. STATCLUS Migration
What happens to existing stats and packages when STATCLUS changes from STANDARD to ENHANCED?
You may be asking what will happen to your application SQL when you change STATCLUS from STANDARD to ENHANCED. Nothing will happen until you run RUNSTATS to implement the improved CLUSTERRATIO calculation described in later slides, and to calculate DATAREPEATFACTORF. Of course, this will still not affect static SQL in your application packages until you BIND the packages. Dynamic SQL will be affected as soon as the statistics are changed for the indexes.
Nothing! Must run RUNSTATS and BIND
Dynamic SQL affected as soon as RUNSTATS runs

11. CLUSTERRATIO Calculation Improvements
Looks at every RID
Considers declining values
Considers size of prefetch window
Point is to improve optimization of index scans
Lets compare the enhanced CLUSTERRATIO calculation in DB2 9 to the way it works in STANDARD mode or in V8.
The V8 algorithm considered one rid in each key value. A key was considered clustered if the rid was higher than that found in the previous key entry. The enhanced algorithm considers all rids, which greatly increases the accuracy of CLUSTERRATIO for lower cardinality indexes. Note that, relative to the previous value, the new CLUSTERRATIO could increase or decrease.
The second improvement is that the enhanced algorithm considers declining values. Dynamic prefetch can be triggered by declining as well as ascending tablespace page numbers.
The V8 algorithm considered any page number increase as clustered, whether it was one page or The enhanced algorithm considers page number differences clustered only if they fit within a sliding window which is based on the prefetch window.
The point of these improvements is to allow the optimizer to make better choices of indexes and of access plan steps to read them, when an index scan is a possible choice to implement data retrieval from a table.

12. CLUSTERRATIO Calculation Overview
Based on analysis of tablespace page referred to by each RID (no need to access tablespace!)
Consider index as list of tablespace page numbers
Want one number that gives average expectation that synchronous I/O will be avoided
Before we get into the details of the CLUSTERRATIOF calculation, lets review very quickly what it is doing and why.
RUNSTATS will calculate CLUSTERRATIOF based on analysis of the table page numbers within the rids in the index entries. In this regard, the contents of the index can be considered a list of table page numbers. One important point is that there is no need for RUNSTATS to access the tablespace itself. All the data it needs for the calculation is in the index.
The goal is to arrive at one number which presents the average expectation that synchronous I/O to the tablespace will be avoided when doing index scans. Note the word “average”; this does not guarantee that the access plan generated by the optimizer will be the best in all cases. The intent is to play the percentages, so that the plan is optimal most of the time.
For partitioned indexes, the CLUSTERRATIOF number will be the weighted average of the cluster ratios derived from each partition. The weighting is by number of rids in each partition.

13. CLUSTERRATIO Calculation
Assume 32K tablespace
Prefetch size is 4 pages (for buffer pool between 3.2M and 160M)
Last page # = 13
73 + 4
This page # = 75 …
New sliding window: 12 to 75
This diagram explains the algorithm to decide whether each page number retrieved from the index is clustered or unclustered. The example we’re using assumes a 32K tablespace in a moderate sized buffer pool (3.2M to 160M), so the prefetch amount will be 4 pages.
Lets assume that at some point during execution of RUNSTATS, the last page found was 13 (numbers are decimal in this example, for simplicity of arithmetic, and only page numbers are shown, not rids). A “sliding window” is maintained, which represents the range of pages previously found. The sliding window is from 11 to 73. If the next page number is within the prefetch amount of either end of this window, it will be counted as clustered and the window will be extended accordingly; if not, it will be counted as unclustered, and the process will start over with a sliding window consisting of the new page number.
However, the sliding window is never allowed to exceed 64 pages, regardless of the prefetch amount. So, if page 75 is the next page number found, the new window would be 12 to 75 (not 11 to 75).
After the entire index has been read, CLUSTERRATIOF is calculated as # Clustered / (# Clustered + # Unclustered). CLUSTERRATIO will be this number multiplied by 100 and rounded to an integer.
Lets look at an example.
Sliding window: 11 to 73

14. CLUSTERRATIO Calculation Details
Example calculation, based on prefetch amount of 8
Could be 16K tablespace in buffer pool with VPSIZE=8000
Page numbers are decimal
Page # 13 35 40 … 96 29
104 3 7
Window after
13-13
35-35
35-40
35-96
33-96
41-104
3-3
3-7
# clustered 1 2 9 10 11 12
#unclustered
This slide explains the CLUSTERRATIOF calculation in more detail, using an example, based on a prefetch amount of 8. This could apply to a tiny 4K buffer pool (less than 224 pages), a small 8K pool (48 to 400 pages), a medium sized 16K pool (200 to 10,000 pages), or a huge 32K pool (more than 5000 pages). All page numbers are in decimal. Again, only page numbers are shown and not the entire rids.
The first page number is 13. It is always counted as clustered, and at this point the sliding window is 13 to 13. The next page is 35; it is higher than 13+8, so it is unclustered, and the range is reset to 35 to 35. The next page is 37, which is within the prefetch range, is therefore clustered, and causes the new window to become 35 to 37. The next page is 40, which is also clustered, and sets the window to 35 to 40. Then follow a string of increments by 8, each of which extends the window until page 96 is read, leaving the window at The next page is 29, which is within 8 of 33, so it is clustered, and it would set the window to 29 to 96; this would be more than 64 pages, so the low end is increased to 33. The next page is 104, which is within 8 of the high end of the window, so it is clustered, and it leaves the window at 41 to The next page, 3, is not clustered because it is more than 8 lower than 41, the low end of the window; the window is reset to 3. Page 7 is also clustered.
Straightforward math gives us a CLUSTERRATIOF value of
The other fact to note is that this is a completely unrealistic example. It is extremely unlikely that a table with 14 rows could span 102 pages.
CLUSTERRATIOF = 12 / (12 + 2) = .8571

15. Does This Work? All rids considered Descending rids “count”
More accurately simulates access to table pages
Descending rids “count”
Supports dynamic prefetch as well as list prefetch
“Oscillating” rids in small range
Within prefetch amount of range “counts”
Gradual trend in page numbers
Will “move” sliding window
How well does CLUSTERRATIOF meet the requirements we considered in slides 6 and 8?
First, as we saw, all rids are considered. This is necessary to model the access to the tablespace which will occur during execution.
Next, descending page numbers in the rids which are “close enough” count as clustered, as well as ascending ones. This allows the optimizer to count on dynamic prefetch being used when it considers CLUSTERRATIOF.
Next, page numbers which go up and down but within a small range defined by the prefetch amount are considered clustered. This allows the optimizer to ignore these minor differences in page number; all such pages will be read during list prefetch or dynamic prefetch.
And last, a gradual trend upwards or downwards in page numbers is considered clustered, if none of the differences between consecutive page numbers exceeds the prefetch amount. This matches the successive prefetches which will happen during execution.

16. What About Partitioned Spaces?
Each partition of index calculated separately
Results averaged for index, weighted by table partition cardinality
NPI’s?
They can include rids from many table partitions
“Switch” in page number from one partition to another is always counted as unclustered
We know the second page won’t be part of the same prefetch!
What about CLUSTERRATIOF for partitioned tables and indexes?
First, for a partitioned index, CLUSTERRATIOF is calculated for each partition, and then a weighted average is calculated. The average is weighted by the number of rows in each partition of the table. This means that REORG TABLESPACE at the part level followed by RUNSTATS for the index can cause skewed information to be provided to the optimizer.
For NPI’s, the calculation is the same; however, you need to know that a rid which refers to a different table partition than the preceding rid is always counted as unclustered. This makes sense because prefetch cannot read data from two different datasets.

17. DATAREPEATFACTORF Calculation Overview
Adds consideration of row density in tablespace
For clustered data, want number to reflect relative probability of buffer hits after asynchronous I/O
Lower is better
Before we consider the DATAREPEATFACTORF calculation in detail, lets review what it is designed to accomplish. It adds a consideration of data density in the table, when accessed via an index scan. As we saw on slide 9, there is a considerable difference between reading 3 pages to access 12 rows, and reading 11 pages to access 12 rows.
Lower numbers are better, so the number reflects the relative number of pages to be read from the tablespace to retrieve a certain number of rows. Again, remember that we are referring only to accesses driven by the rids in an index, so this is not a simple as dividing the number of rows in the table by the number of pages.
If you could build an index in which all the rids referred to one tablespace page, DATAREPEATFACTORF would be 1. At the other extreme, if you had an index such that CLUSTERRATIOF was as close as possible to zero (the only clustered row is the first), DATAREPEATFACTORF would equal the number of rids.

18. DATAREPEATFACTORF Calculation
Assume 32K tablespace
Prefetch size is 4 pages (for buffer pool between 3.2M and 160M)
Last page # = 13
This page # = 75 …
This diagram (basically the same as that in slide 14) explains the algorithm to decide whether each page number retrieved from the index increments DATAREPEATFACTORF. The example we’re using assumes a 32K tablespace in a moderate sized buffer pool (3.2M to 160M), so the prefetch amount will be 4 pages.
Lets assume that at some point during execution of RUNSTATS, the last page found was 13 (numbers are decimal in this example). The sliding window is from 11 to 73. For the DATAREPEATFACTORF calculation, the prefetch amount is irrelevant; it is only the sliding window that applies. If the next page found is outside the window (as in this example), 1 is added to DATAREPEATFACTORF; if it is inside the window, DATAREPEATFACTORF stays the same. So, DATAREPEATFACTORF can be incremented when a page number is counted as clustered (as in this case).
When an unclustered page number is found, DATAREPEATFACTORF is always incremented, before the range is reset.
Lets look at an example. .
Sliding window: 11 to 73

19. DATAREPEATFACTORF Calculation Details
Example calculation, based on prefetch amount of 8
Could be 16K tablespace in buffer pool with VPSIZE=8000
Page numbers are decimal
Page # 13 35 2 10 18 26 3 15
Window after
13-13
35-35
2-2
2-10
2-18
2-26
DRF 1 4 5 6
This slide explains the DATAREPEATFACTORF calculation in more detail.
DATAREPEATFACTORF is always set to 1 when the first page number is found. In this example, we see examples of unclustered references incrementing DATAREPEATFACTORF (like page 35), and clustered references incrementing it (like page 18). DATAREPEATFACTORF ends up with a value of 6, for a table with a cardinality of 9.
This indicates to the optimizer that a row will almost never be found in pages already read during list prefetch. The data is not very dense.
DATAREPEATFACTORF = 6

20. Breathe!
Lets stop for a minute and take a breath. I hope that at this point you understand CLUSTERRATIOF and DATAREPEATFACTORF, and how they are calculated. However, that knowledge is irrelevant unless we can apply it by understanding the effect of these enhanced statistics on the optimizer.
So, now we will look at SQL statements that are affected by enhanced statistics.

21. When Do Enhanced Statistics Matter?
| ACCESSTYPE | MATCHCOLS | ACCESSNAME | INDEXONLY |
| I | | ITEMSHIP | N |
Access must be to the table, through a scan of the index
Most of the time, the significant CLUSTERRATIOF threshold is 80%
7800% change from 1% to 79% doesn’t matter
2.5% change from 79% to 81% does matter
The point of the enhanced calculations for CLUSTERRATIOF and DATAREPEATFACTORF is to provide better information to the optimizer in situations where an index is scanned to access its table. This usually appears as list prefetch or dynamic prefetch. Another possibility is that an index which was previously not selected is now selected, or vice versa. I did not see this happen very often in my research.
Note that the percentage change in CLUSTERRATIOF is irrelevant; what matters is whether a value that exceeded the appropriate threshold now does not, or vice versa.

22. Hybrid Join Example METHOD value of 4 indicates a hybrid join
| METHOD | ACCESSTYPE | ACCESSNAME | SORTN_JOIN| PREFETCH |
| | I | CUSTIX | N | L |
METHOD value of 4 indicates a hybrid join
List prefetch usually selected to access the table
SORTN_JOIN value of ‘N’ indicates the rid list is not sorted…CLUSTERRATIOF for CUSTIX > 80%
Value is ‘Y’ if CLUSTERRATIOF <= 80%
Another fairly common example of the optimizer choosing a path in reaction to CLUSTERRATIOF values is the decision to sort the rid list from the index on the inner table of a hybrid join as part of list prefetch. If the index is 80% clustered or less, the rid list is sorted. If the index is more than 80% clustered, the rid list is not sorted. Sorting could be good or bad, depending on how many rids are in the list, and how much access is improved by sorting them.

23. DATAREPEATFACTORF Example
| METHOD | ACCESSTYPE | ACCESSNAME | INDEXONLY | PREFETCH |
| | I | ORDERCUST | N | L |
Index scan to access a table
PREFETCH is not chosen for CLUSTERRATIOF > 81%
A high DATAREPEATFACTORF (close to number of rows in table) causes selection of prefetch up to 90%
This slide is an example of the optimizer’s use of DATAREPEATFACTORF. In the relatively few tests I ran, it seemed to affect the access path only when the values were relatively high, i.e., the data was not dense. In this example, it caused prefetch to be favored, to handle the higher number of table pages which would have to be read for the same number of rows.

24. When Will ENHANCED Help?
Low CLUSTERRATIOF increases
All rids now counted
Descending rids
Page numbers going up and down within a range
Avoid sorts for hybrid joins, avoid prefetch in nested loop joins
Clustered index with less dense data
Avoid prefetch in index scans
When will moving to STATCLUS ENHANCED improve performance by causing selection of a better access path? Generally, it will be because the improved algorithm for computing CLUSTERRATIOF increases a value which was artificially low. This will be in cases where the rids are really clustered, but were previously not counted as such because they are descending or because they go up and down within a narrow range. More often, this will be simply because all the rids are now included in the calculation. This could lead to avoiding prefetch in cases where it is more costly, or avoiding the sort of the rids during list prefetch in a hybrid join.
For clustered indexes, occasionally the inclusion of DATAREPEATFACTORF will make a difference because the optimizer will make a better choice when the data is not dense.

25. When Will ENHANCED Hurt?
When DB2 was doing the right thing for the wrong reasons
Possible to decrease CLUSTERRATIOF which was artificially high
Where CLUSTERRATIOF increases, maybe prefetch was a good idea
Of more interest possibly are the cases where access paths can change in a bad way because of enhanced statistics. Generally, this will be in cases where the index statistics were incorrect but caused the optimizer to select paths which actually improved performance.
Occasionally, you may see a CLUSTERRATIOF which was artificially high because not all the rids were counted or because the rids were ascending by amounts higher than the prefetch amount. However, avoiding prefetch or the hybrid join sort was the correct thing to do. REORG TABLESPACE should correct such cases, or you could revert to the previous value of CLUSTERRATIOF (see the discussion in a few pages).
Sometimes, you may see a higher value of CLUSTERRATIOF which actually leads to undesirable access paths. Usually, this will be because list prefetch was beneficial and is now avoided.

26. How To Get There? Clone data to ENHANCED DB2?
Might work for limited amount of data
RUNSTATS … REPORT YES UPDATE NONE
Compare reported CLUSTERRATIOF with catalog
Changes above or below threshold
EXPLAIN SQL identified as using indexes of interest
Change SQL if possible
You could just switch to STATCLUS ENHANCED, run RUNSTATS against all your tablespaces and indexes, and then REBIND all your packages and plans, with the idea of fixing performance problems as they arise. This seems unduly risky, particularly if you combine the switch to ENHANCED with migration to V9 from V8. Is there a way to more safely move from STANDARD to ENHANCED?
Even after setting STATCLUS to ENHANCED, nothing changes until you run RUNSTATS. There are a couple of options to consider how to safely run RUNSTATS. One is to copy your DDL and data for all or selected objects to a test DB2 (with ENHANCED set), and run RUNSTATS there. Another is to set ENHANCED on the DB2 you plan to convert, and then run RUNSTATS, specifying “REPORT YES” and “UPDATE NONE”. This will report what CLUSTERRATIOF and DATAREPEATFACTORF would be set to, without updating the catalog. You can then compare these values to those from the catalog, to identify CLUSTERRATIOF values which change significantly (from more than 80% to less, or vice versa).
From there, you need a way to identify the SQL which accesses those indexes. You can then EXPLAIN the SQL, and compare the rows of the PLAN_TABLE with those on your base DB2. For those that have changed, you can change the SQL, provide optimizer hints, or revert the CLUSTERRATIOF values (see next page). Of course, to complete implementation for static SQL, you need to REBIND your packages.

27. Alternatives Use Plan Stability! REBIND…PLANMGMT(EXTENDED)
Creates new “Original” package
If problems, REBIND…SWITCH(ORIGINAL)
Or, copy SYSINDEXES to user table
If problems, revert CLUSTERRATIOF and set DATAREPEATFACTORF to -1
Columns are updatable
Plan Stability is another method to safely transition to STATCLUS ENHANCED. When You REBIND, you can specify PLANMGMT(EXTENDED); this causes DB2 to save your package as the “ORIGINAL” copy. If you have performance problems with the SQL, you can REBIND and specify “SWITCH(ORIGINAL)”, to fall back to the old package. The use of ORIGINAL was designed to support migration from V8 to DB2 9, but there is no reason you cannot use it again for this purpose. Of course, if you do, you may want to time your move to ENHANCED to be an adequate time later than the DB2 version migration. Another thing to be aware of is that use of PLANMGMT(EXTENDED) will increase the space used by SPT01.
Another option to consider is saving a copy of SYSINDEXES (or maybe only the columns of interest – CREATOR, NAME, and CLUSTERRATIOF) in a user table before converting to ENHANCED. Then, if you have performance problems after RUNSTATS and REBIND that you can connect to an index, you can set CLUSTERRATIOF to the original value and set DATAREPEATFACTORF to -1, before doing REBIND. This should get you back to the access plan you had originally. Another advantage of this plan is that it works equally well for dynamic SQL.

28. Bibliography
“DB2 9 for z/OS Performance Topics”, IBM Redbook, SG
“DB2 Version 9.1 for z/OS SQL Reference”, SC
“DB2 9 for z/OS Performance Monitoring and Tuning Guide”, SES
“DB2 Version 9.1 for z/OS Utility Guide and Reference”, SC

29. Questions? Ken McDonald BMC Software Inc. ken_mcdonald@bmc.com
Please me if you want to share your experiences with converting to enhanced statistics.