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

2.1.5 Real storage
DB2 V8 extends upon its improvements in storage management and has also increased
some defaults. All of these changes do not eliminate completely short-on-storage conditions.
You still need to proactively monitor your storage utilization; keep running your DB2 PE
storage statistics reports and watch your storage utilization over time.
You can experience some real storage growth usage when you migrate from DB2 V7 to V8.
The growth is due to a number of factors, the most important is 64-bit addressability, Unicode,
long names support and long key support. The 64-bit instructions are inherently longer than
31-bit counterparts; this effect can increase the size of control blocks that store pointers by a
factor of two. Longer names require larger definitions and space.
You need to make sure that the buffer pools are 100% backed by real storage. DB2 uses an
LRU or FIFO scheme to reclaim pages. As a result, if the oldest pages are paged out to disk,
the paging impact on the system would be significant. In the zSeries architecture, if the buffer
pool is not backed by main storage, the pages would be stored in and out of auxiliary storage
(that is, disks), since there is no configurable expanded storage to provide some hierarchy of
buffering. Expanded storage is not exploited by z/OS in the z/Architecture® modeI. It is wise
to prevent excessive paging to auxiliary storage. Use RFM Monitor II and III to monitor the
real storage frames and auxiliary frames used by the DB2 address spaces. It is very
important to keep in mind that your DB2 subsystem should not page.
Important: Ensure the buffer pools are backed up by sufficient real storage.
2.1.6 Compatibility mode
Once you commit to migrating to DB2 V8, the first stop you make is compatibility mode (CM).
As soon as you are in CM, there is no new function. Well, there is actually some new function;
to start with, DB2 is running in 64-bit mode already, however, there is no new function which
can preclude a fall back to V7. It is not officially documented what is available in CM, and it is
subject to change with maintenance. During this phase, you can test the functionality of
existing applications to ensure they run without problems. Only during this phase can you
revert back to DB2 V7, so once you make the commitment to proceed to the next two stops,
enabling-new-function mode (ENFM) and new-function mode (NFM), there is no turning back.
You will probably remain in CM for a short period of time until you are comfortable that it is
safe to move forward. If you have several DB2-interconnected subsystems, DRDA or
otherwise, migrate all systems to CM before migrating any system to NFM.
Keep in mind that transition among the modes in a data sharing group is an instantaneous
group wide event; it is not possible to have some members in a data sharing group in one
mode while others are in a different mode. All members of a data sharing group are in the
same mode.
Note: Customers typically stay in CM mode for a period of several weeks to a few months.
What we have measured in CM:
► The measurements of the CPU time per commit for non-distributed IRWW workload have
shown a slight increase of 4% in accounting CPU time between DB2 V7 and DB2 V8 CM.
The IRWW workload is described in DB2 for MVS/ESA Version 4 Data Sharing
Performance Topics, SG24-4611. However, there is a considerable decrease in total CPU
time for the DBM1 address space (about 20%).
► Other workloads have a different behavior.
Chapter 2. Performance overview 13