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

2.2 CPU usage
The most common question is “What did you experience in terms of CPU performance
impact?”. In any release of DB2, what the new features cost is a concern. This release
contains a dramatic amount of new function, and because of that, you may experience an
increase in CPU cost. Since DB2 V8 deals with much longer names, and exploits 64-bit
addressing, CPU utilization can increase even if instruction path length does not change. The
number of instructions may not change, but because each instruction is now a 64-bit
instruction instead of a 31-bit instruction, it can be more expensive to execute.
This release also has a number of new SQL functions which usually increases path lengths.
Normally, the target is less than 5% CPU increase from release to release. In V8 the target is
less than 10%.
The assumption, when measuring the CPU regression, is that you do not change the
application to take advantage of any new function. Obviously, once you do rewrite the
application to take advantage of new function, you may even experience a decrease in CPU
time.
When looking at the percent increase in CPU cost, there can be a lot of deviation depending
on a number of different factors, such as:
► Type of workload
– Online
– Batch
– DRDA transaction
– Batch running in DRDA
– Data warehouse
► Characteristics of the workload
– Static or dynamic
– Fetch intensive
– Update intensive
– A combination of the two
– Simple SQL
– Complex query
► Data sharing or a non-data sharing environment
► JDBC or CLI ODBC
► Utilities execution
► Commit frequency and options
There are actions that you can take to mitigate any CPU overhead and we discuss these
actions in the book. One obvious task is to rebind all plans and packages after you migrate.
Once you are in CM, if you rebind, DB2 re-establishes fast column processing and your
application also exploits more efficient access paths, already available under CM, that can
possibly improve CPU costs.
Once you are running in NFM, you can take advantage of more optimization enhancements
after rebind.
For more about new access paths, refer to Chapter 3, “SQL performance” on page 29.
Another optional item of interest to reduce CPU time is the long term page fixing which can be
specified at the buffer pool level; this feature can be enabled in compatibility mode. An
Chapter 2. Performance overview 15