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

8.3.2 Conclusion
The impact of IMMEDWRITE YES remains unchanged. Changed pages are written to the
group buffer pool as soon as the buffer updates are complete, before committing.
With IMMEDWRITE NO (or PH1) and YES options, the CPU cost of writing the changed
pages to the group buffer pool is charged to the allied TCB. Prior to DB2 V8, this was true
only for PH1 and YES options. For the NO option, the CPU cost of writing the changed pages
to the group buffer pool was charged to the MSTR SRB, since the pages were written as part
of phase 2 commit processing under the MSTR SRB.
DB2 V8 now charges all writes of changed pages to the allied TCB, not the MSTR address
space. This enhancement provides a more accurate accounting for all DB2 workloads. DB2 is
now able to charge more work back to the user who initiated the work in the first place.
The impact of changing the default IMMEDWRITE BIND option means that with V8 DB2 no
longer writes any page to the group buffer pool during phase 2 of commit processing. This
change has very little impact on Internal Throughput Rates of a transaction workload and
therefore has little or no performance impact.
However, you may see some increase in CPU used by each allied address space, as the cost
of writing any remaining changed pages to the group buffer pool has shifted from the MSTR
address space to the allied address space.
8.3.3 Recommendations
The IMMEDWRITE enhancements are immediately available when you migrate to DB2 V8.
You do not have to wait until new-function mode.
Customers who use the allied TCB time for end-user charge back may see additional CPU
cost with this change.
8.4 DB2 I/O CI limit removed
8.4.1 Performance
Prior to DB2 V8, DB2 did not schedule a single I/O for a page set with CIs that span a range
of more than 180 CIs. This restriction was in place to avoid long I/O response times.
With advances in DASD technology, especially Parallel Access Volume (PAV) support, this
restriction can now be lifted.
DB2 V8 removes the CIs per I/O limit for list prefetch and castout I/O requests. The limit still
remains for deferred write requests, to avoid any potential performance degradation during
transaction processing. Recall that a page is not available for update while it is being written
to DASD. So, we do not want an online transaction to have to wait for a potentially longer
deferred write I/O request to complete.
A number of performance studies have been done to understand the benefit of removing the
CI limit for DB2 I/O requests. For these studies, the IRWW workload was used in both a data
sharing environment and a non-data sharing environment.
Table 8-12 shows extracts from DB2 PE statistics reports for a non-data sharing environment
running the IRWW workload.
Chapter 8. Data sharing enhancements 333