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

So, we advise you to not overallocate the EDM Statement Cache, but choose a size based on
your needs. Otherwise use the default values. Monitor the EDM Statement Cache and tune it
so that it only contains statements which are frequently in use. Having statements in the
cache which are rarely used can lead to an impact on performance.
Finally, it is worth noting that SQL statements cached in the EDM Statement Pool Cache may
be much larger in V8 than SQL statements cached in V7. This is primarily due to DB2 V8
support for larger names and Unicode.
Compression dictionaries
The compression dictionary for a compressed table space is loaded into virtual storage for
each compressed table space or partition as it is opened. Each compression dictionary
occupies 64 KB bytes of storage (sixteen 4 KB pages).
Moving the dictionary above the 2 GB bar provides significant storage relief for customers
making extensive use of compression. Remember that DB2 V8 can further increase the
compression dictionary storage requirement as V8 also implements support for 4096
partitions for a single table; if they are all compressed and open, you would have 4096
compression dictionaries in memory. Notice that most of the open data set DB2 control blocks
are also above the bar.
The compression dictionary is loaded above the bar after it is built. All references to the
dictionary now use 64-bit pointers. Compression uses standard 64-bit hardware compression
instructions.
SORT pools
Sorting requires a large amount of virtual storage, because there can be several copies of the
data being sorted at a given time.
The DB2 Sort pool is allocated on a per thread basis up to a maximum of 128 MB depending
on the DSNZPARM SRTPOOL parameter. For example, if SRTPOOL=10, then each
concurrent thread doing an RDS sort could allocate up to 10 MB.
Two kinds of storage pools are used for DB2 V8 sort (also known as RDS sort) to store
various control structures and data records. One is a thread-related local storage pool below
the bar, and the other is a thread-related storage pool sort pool above the bar. We estimate
that over 90% of the sort pool is moved above the 2 GB bar.
To take advantage of the 64-bit addressability, some high level sort control structures remain
in thread-related storage below the 2 GB bar. These structures contain 64-bit pointers to
areas in the thread-related storage pool above the 2 GB bar. Sort tree nodes and data
buffers, which comprise 90% of the Sort pool, are located above the 2 GB bar. The maximum
Sort pool size, specified by the DSNZPARM SRTPOOL parameter is 128 MB. In V7 it was 64
MB.
In V7 the RDS OP pool is allocated as a single global storage pool. In V8 this has changed.
The thread-related local storage pool below the bar is now allocated per thread rather than
global. Storage fragmentation can be higher, but contention is reduced since there is no RDS
OP pool anymore.
RID lists for the RID pool
The RID pool is split into two parts. The RID pool part below the 2 GB bar stores the RID
maps which are usually small in number, and the RID pool part above the 2 GB bar contains
the RID lists which normally comprise the bulk of the RID pool storage. Storage size
144 DB2 UDB for z/OS Version 8 Performance Topics