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

Alter Index Padding
In a first test with a non-partitioned table with 17 columns and 1 index the following scenario is
executed and measured:
1. CREATE PADDED INDEX index on C1, C2 and C3, each column being VARCHAR(10)
2. ALTER INDEX to NOT PADDED and REBUILD INDEX
3. ALTER INDEX to PADDED and REBUILD INDEX
4. CREATE NOT PADDED INDEX on C1, C2 and C3, each column being VARCHAR(10)
After each step the CPU time is measured for the following SQL:
FETCH C1, C2, C3... WHERE C1=’XXXXXXXX’ AND C2=’YYYYYYYY’
The results of this measurement are shown in Figure 5-11.
CPU microseconds
30
25
20
15
10
Fetch CPU time …Alter Index Padding
5
0
(1) (2) (3) (4)
padded padded => not padded not padded
ix not padded => padded ix
Fetch CPU time comparison
(2) vs. (1) : +6%
(3) vs. (1) : No difference
(4) vs. (1) : -17%
Figure 5-11 FETCH CPU time - Alter index padded
Index only
access
► After ALTER of the index to NOT PADDED and REBUILD the CPU time for FETCH
increased by 6% (2 vs. 1)
► Altering the index back to PADDED shows no difference in FETCH CPU time compared to
the original situation (3 vs. 1)
► Compared to an index that was created originally with the keyword NOT PADDED there is
a FETCH CPU time increase of 23% (2 vs. 4)
► The impact of NOT PADDED versus PADDED evaluates to a CPU time decrease of 17%
(4 vs. 1) due to index-only access which outweighs the more expensive VARCHARs index
key processing
Note that the access path after the change from PADDED to NOT PADDED did not change to
index-only access.
We repeated this measurement and included a rebind of the application after altering the
index from PADDED to NOT PADDED. See Figure 5-12 for the results.
(1)
N
Chapter 5. Availability and capacity enhancements 237
(2)
N
(3)
N
(4)
Y