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

8.5.5 Buffer pool long term page fixing
DB2 V8 allows you to fix the buffer pages once in memory and keep them fixed in real
storage. This is implemented by new - ALTER BUFFERPOOL parameter called PGFIX. The
ability to long term page fix buffer pool pages in memory and keep them in real storage,
avoids the processing time that DB2 needs to fix and free pages each time there is an I/O.
The ability to page fix buffer pool pages in memory has a significant improvement in DB2
performance, both for data sharing environments and non-data sharing environments.
Although there are still significant CPU savings to be realized in data sharing, the CPU
savings are generally not as much as in non-data sharing. This is because the castout buffers
are NOT long term page fixed.
The primary reason why an overall saving is not as high in data sharing is a higher fixed
overhead of data sharing. A long term page fix applies to GBP read and write. It does not
apply to castout work area, since cast work area is not a part of buffer pool and a long term
page fix is a buffer pool option.
Refer to 4.5, “Buffer pool long term page fixing” on page 169 for a more detailed analysis of
long term page fixing DB2 buffers, both in data sharing and non-data sharing environments.
8.5.6 Batched index page splits
In previous versions of DB2, index page splits for indexes with inter-DB2 read/write interest,
required multiple synchronous log writes and multiple separate writes to the group buffer pool.
This was to ensure that when a leaf page split occurs, the index pages involved are written
out in the correct order, to prevent another member from seeing a reference to an index page
that does not yet exist in the group buffer pool.
This caused significant overhead for GBP-dependent indexes, resulting in additional
synchronous group buffer pool writes, and even more important, in high wait times for
synchronous log I/O.
With this enhancement, DB2 accumulates the index page split updates and processes them
as a single entity, thereby reducing log writes and coupling facility traffic. The writes to the
coupling facility of the accumulated updates use the new z/OS CF Batching commands
described earlier.
However even without CFCC level 12 and z/OS 1.4, (the prerequisites for CF Batching), you
can still take advantage of some performance improvements through this enhancement. In
this case the coupling facility writes are not batched, but the number of forced writes to the log
are reduced to just one or two.
Batching the updates for index page splits will boost performance by reducing the cost of
page set group buffer pool dependency, but even more by reducing the log I/O wait time, is a
more efficient mechanism to process index page splits. Applications which have heavy
insertion activity will see the most benefit in data sharing.
This enhancement does not impact non-data sharing environments or data sharing
environments where the index is not group buffer pool dependent. In these cases, DB2 does
not have to externalize the updated index pages in any particular sequence to be seen
correctly by any other DB2 members.
In both V7 and V8, we see 2 or 3 forced log writes now.
Chapter 8. Data sharing enhancements 339