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

Alter Table Rotate Partition
We executed and measured the following test cases (TC) on a 10 partition table space, a 50
M row table, 1 PI and 0, 1, 3 NPIs:
► TC1 - Delete all rows of partition 1 with SQL
► TC2 - Alter table rotate partition
► TC3 - Load replace with dummy input followed by alter table rotate partition
See Figure 5-18 for the results of the measurements.
Class 1 Elapsed Time
(seconds)
Rotate partition - Elapsed time comparison
500
400
300
200
100
0
TC1 TC2 TC3
1 PI, 0 NPI 1 PI, 1 NPI 1 PI, 3 NPIs
TC1 = Delete Part 1 from Table
TC2 = Alter Table Alter Part Rotate First To Last
TC3 = 1. Load Replace Part 1 w/ Dummy Infile
2. Alter Table Alter Part Rotate First To Last
TC3 can be up to 100 times faster depending on the number of NPIs
Figure 5-18 Rotate partition - Elapsed time comparison
In TC1 we delete all the rows from partition 1. The slight difference with TC2 is due to DB2
predicate evaluation. Also ROTATE uses delete on part 1 but does not have to evaluate a
predicate. If part 1 is emptied first by a dummy LOAD REPLACE elapsed time improves
dramatically. NPIs must be scanned to delete the keys related to rows of part 1, the more
NPIs defined the higher the impact on elapsed time.
Conclusion
Rotate will issue deletes for the partition to be reused. Consider the impact on logging and
performance. A DBD lock will be held for the duration of the ROTATE.
Recommendations
In order to reduce the impact on logging and speed up the delete process consider first
archiving the data in the affected partition and running a LOAD table PART n REPLACE with
a dummy input. Be aware that ROTATE cannot be undone. Backup your data before rotating.
Chapter 5. Availability and capacity enhancements 243