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

from the hiperpools, they were not byte-addressable, and their pages could be stolen any
time. Data spaces were technically byte-addressable, but, for performance reasons, a
lookaside pool was used instead to copy the page. Whenever an application tried to read data
from a data space buffer page, the page was copied from the data space into this temporary
work area within the 2 GB address space.
Another disadvantage of data spaces and hiperpools is that the control blocks representing
these buffers resided in the 2 GB address space. These control blocks created a practical
limit to the size of the buffer pools, depending on other demands for virtual storage in the
DBM1 region. Given the control block storage requirements, it is unlikely that a single DB2
member could exploit all of the central storage that a z/Series processor is capable of
supporting, which is now up to 256 GB, and growing.
DB2 V8 no longer supports data spaces or hiper pools since 64-bit addressing makes them
obsolete. DB2 V8 stores all buffers above the bar. DB2 does I/O directly into and out of the
buffers and never has to copy the data merely to facilitate byte addressability. DB2 systems
management and operations tasks are simplified and the cost of data moves is reduced.
As of DB2 V8, the terms buffer pool and virtual pool become synonymous, with the tendency
to use just the term buffer pools.
Buffer pools can now scale to extremely large sizes, constrained only by the physical memory
limits of the machine (64-bit allows for 16 exabytes of addressability). However DB2 imposes
a 1 TB limit, as a safety valve for real storage available, as follows:
► The maximum size for a single buffer pool is 1 TB.
► The maximum size for summation of all active buffer pools is 1 TB.
The buffer pool control blocks, also known as page manipulation blocks (PMBs), are also
moved above the 2 GB bar. Castout buffers used for data sharing, are also relocated above
the bar.
When you first migrate to V8, DB2 determines the buffer pool size based on the following
equation:
VPSIZE + HPSIZE = BPSIZE
We therefore recommend you review your virtual buffer pool sizes and your hiperpool buffer
sizes before you migrate to V8 to make sure you have enough real storage to fully back the
new default buffer pool sizes (see 2.7, “New installation default values” on page 24.).
You also need to adjust down the buffer pool thresholds, since they were initially set up for the
write activity of just the relatively small virtual pools.
The EDM pool
The Environmental Descriptor Manager (EDM) deals with the DB2 metadata of your
databases and applications. It caches and manages the following objects in the EDM pool:
► Data base descriptors (DBDs), skeleton cursor tables (SKCTs), skeleton plan tables
(SKPTs), cache blocks for plans, and skeleton dynamic statements (SKDSs)
► Private user versions of the plan (CTs and PTs) during execution
► Authorization cache
DBDs in the EDM pool
In V8, almost all of the storage related to managing DBDs is allocated above the 2 GB bar.
This gives the DBDs the needed space to grow and relieves contention with other objects in
the EDM pool. DBDs are also larger in DB2 V8 in new-function mode. The size of the DBD
142 DB2 UDB for z/OS Version 8 Performance Topics