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

8.1.2 Conclusion
not all that significant for our OLTP workload, while the overall impact on our batch workload
was indeed significant.
CF request batching also benefits DB2 performance in other ways. DB2 commit processing
performance is improved, where any remaining changed pages must be synchronously
written to the group buffer pool during commit processing. For GPBCACHE(ALL) page sets,
DB2 is able to more efficiently write prefetched pages into the group buffer pool as it reads
them from DASD.
CF request batching allows DB2 V8 to reduce the amount of traffic to and from the coupling
facility for both writes to and reads from the group buffer pool for castout processing, thus
reducing the data sharing overhead for most workloads.
The most benefit is anticipated for workloads which update large numbers of pages belonging
to GBP-dependent objects, for example, batch workloads.
This enhancement also has potential to reduce the CPU used by the DBM1 address space,
as fewer messages are passed to and from the coupling facility. Coupling facility link
utilization may also decrease slightly. As a consequence, coupling facility utilization may be
slightly higher as message service times increase. This is a direct result of the coupling
facility having to perform more work to service each batched request. The data sharing
overhead caused by castout processing is also reduced.
8.1.3 Recommendations
There is nothing you need to do in DB2 to enable DB2 to use CF request batching. However,
you need to have the prerequisite software in place, z/OS 1.4 and CFCC Level 12.
We recommend you implement a strategy to keep reasonably current with software
maintenance and coupling facility microcode levels, in order to take early advantage of
enhancements such as CF request batching. This is particularly important in a data sharing
environment.
8.2 Locking protocol level 2
Protocol Level 2 remaps parent IX L-locks from XES-X to XES-S locks. Data sharing locking
performance benefits because this allows IX and IS parent global L-locks to be granted
without invoking global lock contention processing to determine that the new IX or IS lock is
compatible with existing IX or IS locks.
The purpose of this enhancement is to avoid the cost of global contention processing
whenever possible. It will also improve availability due to a reduction in retained locks
following a DB2 subsystem or MVS system failure.
Refer to section 11.1 of DB2 UDB for z/OS Version 8: Everything You Ever Wanted to Know,
... and More, SG24-6079, for a general review of locking in a data sharing environment.
XES contention caused by parent L-Locks is reasonably common in a data sharing
environment. On page set open (an initial open or open after a pseudo close) DB2 normally
tries to open the table space in RW. (DB2 rarely opens a table space in RO.) To do this, DB2
must ask for an L-Lock. This L-lock is normally an IS or IX L-lock, depending on whether or
not a SELECT or UPDATEable SQL statement caused the table space to open. If any other
Chapter 8. Data sharing enhancements 325