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

Generally, you should experience more CPU regression if:
► You use non-padded indexes (the default in V8 install) with small varchar columns.
There is a fixed CPU overhead in processing varchar columns in INDEX KEY. As the size
of each varchar column increases, the overhead gets not only diluted but eventually it can
result in positive performance gain. See Chapter 5, “Availability and capacity
enhancements” on page 217 for more details and information about changing the default.
► You use DPSIs in some SQL statements.
DPSIs can currently only be non-unique. Some queries, for example, queries with
predicates which only reference indexed columns of the index, may experience some
performance degradation. These types of queries may need to probe each partition of the
DSPI, where only one probe was needed for an NPI. Additional qualifiers might help.
► You manipulate lots of columns in your SQL.
This code has already been heavily optimized over the years and in V8 it carries the
overhead due to 64-bit processing. Reducing the number of columns to the ones really
needed is always advisable.
Impact on class 2 CPU time
As you begin to review the CPU utilization for your workload in V8 compared with V7, keep in
mind that you may see a slightly higher accounting class 2 CPU time in V8. However the news
is not all bad. Table 4-3 compares the increase in accounting class 2 CPU times to the overall
CPU consumed.
Table 4-3 Accounting class 2 CPU time increase
Accounting class 2
CPU time
MSTR/DBM1/IRLM
CPU time
Non-data
sharing
+6% +14%
-14% -51%
Total +1% -9%
Data sharing
We can see that for our tests Accounting class 2 CPU times have increased by 6% for
non-data sharing and 14% for data sharing in V8 compared to V7.
As we have mentioned earlier, 64-bit addressing has brought its own performance challenges
to DB2. 64-bit instructions are typically twice as big as 31-bit instructions and some 64-bit
instructions can take as much as 15% more CPU to execute. This impacts class 2 CPU time.
This is what contributed to driving the accounting class 2 CPU times higher in DB2 V8.
New DB2 V8 function, like removing the 180 CI limit for list prefetch and castout processing,
and long term page fixing of DB2 buffers, works to decrease the overall SRB CPU time, which
in turn offsets the increase in accounting class 2 CPU times.
The higher class 2 CPU time in data sharing compared with non-data sharing (14%
compared with 6%) is largely attributed to the changes V8 has introduced to the
IMMEDWRITE BIND option. In V7, DB2 charges the CPU for writing changed pages to the
group buffer pool at commit, to the MSTR address space. In V8, this cost is charged to the
allied address space. The cost of writing these changed pages has moved from the MSTR
address space to the allied agents Accounting class 2 CPU times. See the discussion on
IMMEDWRITE in Chapter 8, “Data sharing enhancements” on page 319 for more details.
Chapter 4. DB2 subsystem performance 137