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

2.5.5 Fast log apply
Once you migrate to DB2 V8 CM, the new default for fast log apply (FLA) is 100 MB. This
should have a minimal effect on DBM1 storage. FLA is used by the RECOVER utility, during
restart of a failed DB2, or when RESTORE SYSTEM is used. The storage is allocated when
needed and released when the FLA phase is complete.
When multiple RECOVER utility jobs are run in parallel, DB2 can take advantage of FLA for
up to 10 concurrent jobs, each utilizing 10 MB.
The default value for FLA at restart is always 100 MB, even if you explicitly specify 0 in the
DSNTIPL panel or in the DSNZPARM LOGAPSTG.
During RESTORE SYSTEM, a new utility with DB2 V8, the default value for FLA (if
LOGAPSTG is not zero) is 500 MB.
For more information on FLA and its performance implications, refer to Chapter 4, “DB2
subsystem performance” on page 127 and Chapter 5, “Availability and capacity
enhancements” on page 217.
2.5.6 Multi-row operations with DRDA
2.5.7 IRLM V2.2
DB2 V8 CM automatically exploits multi-row fetch when you use a remote client that uses
block-fetching in a distributed application. The DDF address space uses multi-row fetch to
build the blocks of data to be sent to the client. This implies you do not have to change the
application to take advantage of this tremendous performance enhancement. We have
experienced performance improvements in these client applications in DB2 V8 CM.
For more information on the multi-row fetch operations with DRDA, refer to Chapter 7,
“Networking and e-business” on page 281.
The IRLM address space also changes with DB2 V8 and supports 64-bit virtual addressing.
The IRLM is able to support more concurrent locks. PC=YES is now enforced when you
migrate to DB2 V8. The ECSA usage (PC=NO) capability can still be specified, but is no
longer used by V8. Therefore, the ECSA previously used for IRLM, if you used PC=NO, could
now be available for use by other applications.
Important: If you used PC=NO, review your ECSA usage, since potentially there can be
less of a need for ECSA with IRLM V2.2.
Real storage for IRLM locks increases significantly, since they have doubled in size. For more
information on the IRLM in 64-bit mode, refer to Chapter 4, “DB2 subsystem performance” on
page 127.
2.5.8 Page-fixed buffer pools
DB2 V8 introduces a new buffer pool parameter called PGFIX which allows you to choose to
fix buffer pools in real storage. Before reading or writing a page, DB2 must fix the page in real
storage in order to perform the I/O. In DB2 V8, with this new buffer pool option, you can
decide to permanently page fix an entire buffer pool. The option to page fix a buffer pool is
available in CM, but is not automatically enabled.
Chapter 2. Performance overview 21