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

► CHAR(8) to VARCHAR(8)
► CHAR(8) to CHAR(10)
► INTEGER to DECIMAL(10,0)
The CPU time (microsec.) for FETCH and INSERT before ALTER, after ALTER and after
REORG are measured. Figure 5-8 shows the results for FETCH.
CPU time (microseconds)
30
25
20
15
10
5
0
C8 =>VC8 C8 =>C10 Int =>Dec
Figure 5-8 CPU time before ALTER, after ALTER and after REORG
A performance degradation of 21% to 23% is measured after ALTER and before REORG.
After reorganization the performance overhead remains below 5%.
The performance fluctuation reflects the change of format and that “fast path for column
processing” is disabled after ALTER and re-enabled again after reorganization of the table
space. Even improved performance after reorganization is possible, depending on the new
data type as some data types tend to be less CPU intensive, for example change from
decimal to integer.
Fast path for column processing was introduced in DB2 V4. For SELECT, FETCH, UPDATE
and INSERT, DB2 will process each column definition for the first three rows. For the fourth
and subsequent rows DB2 generates and uses an optimized procedure to access further
rows.
Figure 5-9 shows the results for INSERT.
234 DB2 UDB for z/OS Version 8 Performance Topics
Before Alter
After Alter (AREO*)
After Reorg (reset
AREO*)