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

Class 1 Elapsed Tim
(Seconds)
Reorg Rebalance… Elapsed Time
1000
800
600
400
200
0
Figure 5-20 REORG REBALANCE elapsed time
TC1 TC2
1 PI, 0 NPI 1 PI, 1 NPI 1 PI, 3 NPIs
Partition distribution : 8(5M) + 1(1M) + 1(9M)
TC1 - reorg tsp rebalance all parts
TC2 - reorg tsp rebalance parts 9 and 10
40% to 80% faster if Reorg Rebalance parts 9 and 10 only
In test case 1 all partitions are read and updated even if not all partitions needed to be
rebalanced. Depending on the number of NPIs REORG REBALANCE runs 40% to 80%
faster if only partition 9 and 10 are rebalanced.
Conclusion
Rebalancing could be executed in prior versions of DB2 by altering the partitioned index limit
keys followed by a reorganization. But the affected partitions were placed in a REORGP state
and the data was unavailable until the reorganization completed. Rebalancing can be done
with SHRLEVEL REFERENCE and so the data remains available for readers almost all the
time. Only during the switch phase, the data is unavailable. It is also during the switch phase
that DB2 updates the limit keys to reflect the new partition boundaries.
Recommendations
The use of rebalancing instead of altering the partitioned index key limits will enhance the
availability of your data.
Note: REORG REBALANCE might not be possible if the logical and physical partition
numbers for the specified table space do not match. This situation can be created by a
series of ALTER ROTATEs and ALTER ADD PARTs. The partition range that you specify
on the REORG REBALANCE statement is a range of physical partitions. When
rebalancing, DB2 unloads, sorts, and reloads the data based on logical partition numbers.
Message DSNU1129I is issued and REORG terminates.
Chapter 5. Availability and capacity enhancements 245