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

application that can have great potential benefit is one using a buffer pool with a poor read hit
ratio and lots of I/O. Writes also benefit from page fixing.
We explore this topic in more detail in Chapter 4, “DB2 subsystem performance” on
page 127.
There are new functions in DB2 V8 where we experienced a decrease in CPU cost. We use
two new functions at the SQL level to minimize the CPU impact of migrating to DB2 V8:
Multi-row insert and multi-row fetch. These new functions require application changes, but
can offset an increase in CPU cost of an insert intensive or fetch intensive application and are
worth exploring for those applications that apply. You will find a discussion of multi-row insert
and multi-row fetch in Chapter 3, “SQL performance” on page 29.
For those applications that were are virtual storage-constrained with V7, there are a number
of areas for possible CPU improvements. One is, if you are using data space buffer pools or
hiperpools with V7, once you migrate to DB2 V8, DB2 replaces these pools with buffer pools
residing above the 2 GB bar, and fewer instructions are needed for their management. If your
system can use real storage for bigger buffer pools, I/O can be reduced and this results in
CPU savings, especially for those applications using a lot of synchronous I/O for critical batch
processes.
If you are using DSNZPARMs MINSTOR and/or CONTSTOR to contract and minimize thread
storage consumption, and thread storage consumption is not the major consumer below the 2
GB DBM1 storage, you can reset them to free up much needed virtual storage for other use
and gain back the CPU overhead of running these processes.
You can find more information on buffer pools, MINSTOR and CONTSTOR in Chapter 4,
“DB2 subsystem performance” on page 127.
Warning: When doing performance measurements between different releases of DB2,
make sure you take a look at the whole picture. An increase in class 2 CPU time may be
offset by a reduction in SRB or TCB time in the DB2 address spaces. We recommend you
take both sets of numbers into account when doing comparisons since the CPU time may
now be charged to the application owning TCB and less to one of the DB2 address spaces.
The information needed to do a proper analysis would be spread across accounting and
statistics reports.
2.3 DBM1 virtual storage mapping
The limitation of virtual storage in the DBM1 address space prior to V8 is a serious problem
and one of the primary reasons customers cite as their motivation for moving to DB2 V8.
Virtual storage is not something you can buy; it is inherent in the software product’s
architecture. Prior to DB2 V8, the amount of virtual storage available is limited by the 31-bit
addressing scheme which equates to an address space capable of addressing limited to 2
GB.
If you have been virtual storage-constrained, you have most likely done one or more of the
following to get some storage relief:
► Moved your virtual pools to data spaces
► Used the data space extension of the EDM pool for the (global) dynamic statement cache
► Used DSNZPARMs CONTSTOR and MINSTOR if using long running threads to minimize
thread-related storage
16 DB2 UDB for z/OS Version 8 Performance Topics