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

Important:
4.1.2 Conclusion
If you plan to stay in CM for some time and are interested in finding out the performance of
V8 on your performance-sensitive workload, you should definitely rebind. Rebinding will
give you a sense of the V8 performance.
After you have entered NFM, we recommend that you plan to rebind all of your plans and
packages. DB2 then stores these plans and packages in the DB2 catalog in the new
format. DB2 will then no longer need to expand the plans and packages each time it needs
to use them.
For most workloads, our measurements have shown a less than 10% increase in CPU
consumed by moving from V7 to V8, and we did not even change applications to take
advantage of any new function or make any aggressive configuration changes. In addition,
the difference in CPU consumption between DB2 V8 CM and NFM is only minor and
therefore should not be considered significant.
Generally, you should experience less CPU regression if, under DB2 V7:
► You are already using IRLM PC=YES and LOCKPART YES.
In V8 these are required.
► You are heavily using hiperpools or buffers in data spaces in V7.
You are taking advantage of simplified buffer pool management above the bar.
► You already use CURRENTDATA(NO) in your BIND options.
CURRENTDATA(NO) already exploits lock avoidance in V7.
► You collect SMF type 89 records.
V7 generates these records after every SQL statement while V8 generates these records
on each commit. In some environments, this has the potential of saving up to 15% in CPU
consumed by DB2 V8 (extreme stress environment).
► You heavily use DSNTEP2 (now DSNTEP4) and DSNTIAUL which now exploit multi-row
operation. This is applicable to NFM only.
► You heavily use DRDA which now automatically exploits multi-row operation. This is
applicable to CM as well as NFM.
Multi-row FETCH/INSERT/UPDATE have the potential to save considerable CPU,
especially in DRDA applications.
► You have the DSNZPARM MINSTOR and CONTSTOR parameters set to YES and are not
thread storage constrained.
Having these parameters set to YES in V7 uses extra CPU cycles. Once in V8, if you can
set them to NO, this improves the CPU time.
► You use BIND RELEASE(COMMIT) in data sharing.
In V8 there is potentially less global lock contention as a result of the Locking Protocol
Level 2. DB2 V7 must use more CPU cycles to resolve more global lock contention than
V8, which potentially has less global lock contention.
► You have I/O intensive workloads.
I/O intensive workloads tend to benefit from long term page fix option and 180 CI limit
removal. Sequential processing with larger CIs can also benefit.
136 DB2 UDB for z/OS Version 8 Performance Topics