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

DB2 AS class 2 CPU time
(msec / commit)
MSTR 0.309 0.336 0.135 0.150 0.150 0.150 - 56% + 0%
DBM1 0.603 0.621 0.451 0.447 0.436 0.434 - 27% - 3%
IRLM 0.330 0.371 0.331 0.337 0.014 0.014 - 5% - 96%
Total 1.243 1.328 0.917 0.974 0.600 0.597 - 27% - 63%
DB2 class 2 CPU
+ Total
DB2 V7 DB2 V8 CM DB2 V8 NFM Delta
(CM / V7)
3.447 3.708 3.357 3.617 3.125 3.105 - 3% - 11%
Delta
(NFM / CM)
In these measurements, we see a large 11% decrease in overall CPU used in NFM compared
to CM. This is not due to the extra overhead in running in CM over NFM, but as a direct result
of Locking Protocol Level 2 being used in NFM, but not available in CM. These savings are
realized through a dramatic reduction in the IRLM CPU times. See 8.2, “Locking protocol level
2” on page 325. We can also see the positive impact the Locking Protocol Level 2 has on
transaction response times, with quite a significant savings in transaction elapsed time. The
drop in transaction elapsed time is caused by a similar drop in application class 3 suspend
time, which is not listed in the table.
We see a slight decrease in overall CPU (3%) used in DB2 V8 CM compared with DB2 V7.
This is a better result than with non-data sharing. In addition to the performance gains we see
through Long Term Page Fixing the buffer pools, data sharing offers more CPU savings
through functions such as CF Request Batching which are specific to data sharing. See
Chapter 8, “Data sharing enhancements” on page 319 for a more detailed discussion of these
enhancements. All these enhancements combine to offer a far greater offset to the CPU
increase in DB2 V8.
Compatibility mode versus new-function mode
DB2 V8 brings a new strategy to move an existing DB2 V7 environment to Version 8. You
must first ‘migrate’ your DB2 environment from Version 7 to Version 8 compatibility mode
(CM). You can fallback to DB2 V7 if you need to, and only partial new Version 8 function is
enabled. Once you are comfortable with the function, stability and performance of DB2 V8 in
CM, you then move through enabling-new-function mode (ENFM) and into new-function
mode (NFM). Once in NFM, you can now exploit all the new function in DB2 V8, but you
cannot return to CM or Version 7. See Chapter 9, “Installation and migration” on page 341.
Some users may choose to remain in CM for a period of a few weeks or even a month or two.
While other users may choose to migrate to NFM at their earliest opportunity.
Once in CM, DB2 parses all SQL statements in Unicode. In addition, DB2 V8, both in CM and
NFM, uses a different format for its DBDs, packages and plans. DB2 V8 requires a new
format for DBDs, plans and packages to support the new function such as Unicode and Long
Names. So, before DB2 can use a DBD, plan or package from an earlier release of DB2, it
must first expand it into the new V8 format. In CM, DB2 must also convert the DBDs, plans
and packages to the old format before it can store them in the catalog. This extra overhead is
recorded in DB2 class 2 CPU times, and is extra overhead that exists while running in CM and
NFM without which you can easily function.
Chapter 4. DB2 subsystem performance 135