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

4.5.2 Conclusion
The performance improvements in a data sharing environment are not as pronounced, with
only a 19% improvement in DBM1 CPU used, compared with 29% in non-data sharing. The
main reason is a higher fixed cost with data sharing.
Remember that our measurements were taken using an I/O intensive workload. You might not
see as dramatic an improvement in CPU savings as we did. However our test cases show a
CPU time reduction of up to 8% for I/O intensive transaction workload, and as much as 10%
for more I/O intensive batch types of workloads.
Although these are still significant CPU savings to be obtained in a data sharing environment,
the CPU savings are generally not as great as in a non-data sharing environment. This is
primarily due to a higher fixed cost overhead with data sharing.
4.5.3 Recommendations
4.6 IRLM V2.2
Long term page fixing DB2 buffer pools is effectively a trade-off between real storage and
performance. It is available in V8 CM and beyond.
Long term page fixing of DB2 buffer pools typically results in a CPU savings in the range of
0% to as great as 10%. The performance benefits are inversely proportional to the buffer pool
hit ratio. The higher the hit ratio, the lower the potential performance benefit. We therefore
recommend you first page fix your smaller buffer pools with a low hit ratio and frequent I/O,
(for example sequential workloads). You then should consider page fixing your other buffer
pools, buffer pool by buffer pool, to minimize potential impact on other concurrently running
workloads. However, you need to be a little more cautious when considering larger buffer
pools. Page fixing buffer pools may drive system paging rates higher, thereby impacting
overall system performance.
We cannot overstress the importance of having sufficient real storage to back up your buffer
pool 100%. Having 99.9% is not good enough, as the LRU buffer steal algorithm introduces
paging if there is insufficient real storage to back up your buffer pool completely. Therefore,
make sure your buffer pool is fully backed by real storage before you start using PGFIX(YES).
DB2 V8 is shipped with IRLM V2.2, which is now a 64-bit application. With IRLM V2.2, DB2
locks always reside above the 2 GB bar.
IRLM V2.2 ships with both a 31-bit version of the modules, as well as a 64-bit capable
version. If the operating system is able to handle 64-bit, the 64-bit version is loaded. However,
the interface to IRLM V2.2 is still 31-bit. The 64-bit version requires the z/Architecture as well
as z/OS 1.3. DB2 V8 requires IRLM V2.2 in 64-bit mode.
IRLM V2.2 is also shipped with IMS V9. However, note that at the time of writing this book,
IRLM V2.2 does not support earlier versions of DB2 or IMS.
IRLM V2.2 supports a far greater number of locks than V2.1. IRLM V2.1 which is shipped with
DB2 V7, is a 31-bit application and is therefore restricted to the 2 GB address space limit. The
maximum number of concurrently held locks in IRLM V2.1 is approximately 8 million locks, (2
GB/approximately 260 bytes per lock). IRLM V2.2 which is shipped with DB2 V8, is a 64-bit
application and therefore not restricted to the 2 GB address space limit. As the average lock
size in DB2 V8 is increased to approximately 540 bytes, only 3.7 million locks can be
Chapter 4. DB2 subsystem performance 171