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

Attention:
4.2.1 The DB2 pools
LOBs use data spaces with versions prior to V8, and go above the bar in the DBM1
address space with DB2 V8, so they are not influential with respect to VSCR.
If you were using data spaces (max 8 M pages each), and have allocated their buffer pools
and global dynamic statements cache (DSC) instead of below the bar in the DBM1
address space, then the VSCR would be less.
If you were using hiper pools (max 8 GB total) to work as cache for your virtual buffer pools,
then the VSCR would be less.
The GETMAIN and FREEMAIN processes to acquire and release virtual storage in z/OS can
be quite expensive in terms of instructions. So, DB2 tends to GETMAIN large blocks of
storage from z/OS and then manage the sub-allocation and usage directly.
DB2 maintains two main types of storage pools:
► Stack storage (SKB): Used for very active thread-related storage.
► Getmained block (GMB) storage: Used for specific purposes such as buffer pools,
compression dictionaries, and so on. With DB2 V7 this is generally the largest user of
storage below the bar in the DBM1 address space. Storage in the GMB pool includes:
– Buffer pools and buffer pool control blocks
– EDM pool
– Compression dictionaries
– Data space lookaside buffers (V7)
– Data space buffer pool control blocks (V7)
– Hiper pool control blocks (V7)
Pools can also be fixed pools, in which the storage is sub-allocated into the same length
blocks and optimized for performance or variable pools, which are general use pools of
storage, sub-allocated into variable length blocks.
Some storage pools are global and shared by multiple threads, for example buffer pools and
the EDM pool. In these pools fragmentation is generally smaller, however contention can
sometimes be a problem. While other types of storage are thread-related and only used by a
single thread, for example, stack, storage and variable pools. In these other types of pools,
fragmentation is a bigger problem but contention is much lower. Generally the largest
contributors to virtual storage usage are GETMAINed and variable pools; however, the trend
in the last few years has been toward growing usage of stack, thread-related, and storage.
We now examine what has changed with DB2 V8 in terms of storage management.
64-bit virtual buffer pool support
The buffer pools are used by DB2 to reduce disk accesses. With more and more data needed
by the applications, larger buffer pools have become necessary. The 64-bit virtual addressing
is seen as the third major step in the evolution of MVS in the last 30 years. The first step was
the transition from MVS/370 (24-bit) to MVS/XA (31-bit). The second step was the
transition to MVS/ESA (including data spaces and hiper pools).
DB2 V7 supported buffer pools in data spaces and hiperpools. They both facilitated larger
buffer pools. They each had their advantages and disadvantages. We could not do I/O directly
Chapter 4. DB2 subsystem performance 141