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

See 4.3, “Monitoring DBM1 storage” on page 157 for the contents of the 225 record.
► The DSNZPARM CONTSTOR parameter
The CONTSTOR parameter determines whether or not thread storage contraction is to be
performed. Storage contraction tries to free up allocated storage that is no longer in use by
attempting to contract thread local storage pools at commit. If CONTSTOR is set to YES,
two other thresholds are used to govern when storage contraction is performed for a
thread.
– SPRMSTH provides a threshold for the amount of storage allocated to a thread before
contraction occurs.
– SPRMCTH provides a threshold for the number of commits performed by a thread
before contraction occurs.
► The DSNZPARM MINSTOR parameter
The MINSTOR parameter is used to direct DB2 to use storage management algorithms
that minimize the amount of working storage consumed by individual threads, when DB2
allocates thread-related storage from local storage pools for threads. Essentially, a best fit
storage search algorithm is used instead of a first fit algorithm. The trade-off is less
storage fragmentation however slightly more CPU may be consumed.
MINSTOR should normally be set to its default, NO. However, for subsystems that have
many long-running threads and are constrained on storage in the DBM1 address space,
specifying YES may help reduce the total storage used in the DBM1 address space.
► The DSNZPARM MAXKEEPD parameter
The MAXKEEPD parameter indirectly controls the size of the Local Dynamic Statement
Cache, which is allocated at the thread level. MAXKEEPD specifies the total number of
prepared, dynamic SQL statements to be saved past commit. This is a system wide limit,
which is enforced at the thread level when the next commit point is reached for the thread.
The Local Dynamic Statement Cache provides for prepare avoidance and the Global
Dynamic Statement Cache (now above the bar in V8) provides for short prepares. Prepare
avoidance is cheaper than a short prepare, but the cost of a short prepare is much
cheaper (100x) than a typical long prepare.
A suggested tuning approach based on trading CPU for virtual storage constraint relief is
to incrementally reduce the size of the Local Dynamic Statement Cache by reducing
MAXKEEPD, even setting it to zero, and then monitor performance and storage utilization.
You may have to increase the Global Dynamic Statement Cache to compensate, if the
Global Dynamic Statement Cache Hit Ratio starts to deteriorate.
In V7, MAXKEEPD has a default of 5000 statements. As the MAXKEEPD threshold is only
evaluated at commit, it is common to see the number of SQL statements cached exceed
this limit. This is not a problem. For a description of MAXKEEPD at V7 level, see the article
DB2 UDB for OS/390 Storage Management by John Campbell and Mary Petras, published
in The IDUG Solutions Journal Spring 2000 - Volume 7, Number 1.
► Short prepare performance enhancement
The short prepare copies a referenced statement from the EDM statement cache pool into
the Local Dynamic Statement Cache and sets it up for execution. The overhead varies
depending on the statement execution time but may be 1-2% for long running statements.
There is one Local Dynamic Statement Cache pool allocated for each thread in DB2 V7.
This has changed in V8. Now the Local Dynamic Statement Cache is allocated in an array
of 30 global pools. This change should reduce the storage fragmentation below the bar,
however some contention may occur as a result.
The new approach aims to reduce the cost of the OS level GETMAINs and FREEMAINs
by going to a centralized storage approach. With this approach, DB2 uses a number of
146 DB2 UDB for z/OS Version 8 Performance Topics