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

Be aware that IFCID 225 represents a “snapshot” of DBM1 storage usage at a particular point
in time. On an active subsystem, it is not uncommon for DB2 to be in the process of allocating
storage while freeing up other storage. So, the numbers presented in IFCID 225 may keep
changing and do not always add up. However, they become consistent after a while and can
be used as a good guide to what is happening in the DBM1 address space. In addition, keep
in mind that these numbers show the DB2 side. MVS has a different picture which tends to be
more pessimistic. DB2 generally acquires storage from MVS in chunks but may not
immediately use the storage for any particular purpose within DB2. MVS sees the whole
chunk as being allocated and used.
We have seen that DB2 maintains four main types of storage:
► Stack Storage (SKB): Used for very active thread-related storage.
► Getmained Block (GMB) Storage: Used for specific purposes such as buffer pools and
compression dictionaries.
► Fixed pools : Storage is sub-allocated into the same length blocks and optimized for
performance.
► Variable pools: General use pools of storage, sub-allocated into variable length blocks.
In this example, the TOTAL DBM1 STORAGE BELOW 2 GB is 779.63 MB.
This total can be split up into the following components:
► TOTAL GETMAINED STORAGE = 599.18 MB
► TOTAL VARIABLE STORAGE = 153.39 MB
► TOTAL FIXED STORAGE = 0.30 MB
► TOTAL GETMAINED STACK STORAGE = 26.77 MB
GETMAINED Storage
The TOTAL GETMAINED STORAGE is storage acquired by DB2 as GETMAINed Blocks
(GMB). In V7, this is generally the largest consumer of storage in the DBM1 address space. It
includes space for virtual buffer pools, virtual buffer pool control blocks, the EDM pool,
compression dictionaries, castout buffers, the data space lookaside buffers, hiper pool control
blocks and data space buffer pool control blocks. We can see these indented in the report.
Note however that these numbers may not add up to TOTAL GETMAINED STORAGE
because DB2 does not collect statistics on all GETMAINed storage.
Buffer pools are usually the major consumers of DBM1 storage.
► The storage required for the virtual buffer pools is shown by the following indicator:
– VIRTUAL BUFFER POOLS = 437.50 MB
► Independent of the page size, a control block of 128 bytes (V7) or 144 bytes (V8) is
allocated for each page in the virtual buffer pool. The storage required is shown by the
following indicator:
– VIRTUAL BUFFER POOL CONTROL BLOCKS = 13.67 MB
► Hiperpools are not allocated in the DBM1 address space but storage is allocated inside
the DBM1 address space for the 56-byte hiperpool control block associated with each
hiperpool buffer. The storage required is shown by the following indicator:
– HIPERPOOL CONTROL BLOCKS = 0 MB (hiperpools are not used here)
► If you allocate the buffers to data spaces (V7), additional storage is required in the DBM1
address space. A control block of 128 bytes is allocated for each data space buffer
defined. The lookaside buffers also utilize a sizable amount of DBM1 virtual storage. The
storage required is shown by the following indicators:
Chapter 4. DB2 subsystem performance 159