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

DB2 V8 in new-function mode increases the number of active log data sets from 31 to 93,
allowing DB2 to keep more log data online and therefore available for any recovery.
In addition, DB2 V8 in new-function mode increases the number of archive log data sets DB2
remembers from 1,000 to 10,000. This increases the amount of log data DB2 is able to
access and use in recovery, therefore satisfying the larger window often required by Service
Level Agreements (SLA).
4.13.2 Up to 65,041 open data sets
DB2 V8 increases the number of open data sets from 32k to 65,041. This enhancement is
available starting with z/OS V1.5 base code.
Open data sets require storage for MVS control blocks below the 16 MB line. This has been
the cause of virtual storage constraint problems below the 16 MB line in the past. Dynamic
allocations can request these control blocks to be allocated above the 16 MB line. With z/OS
V1.5, media manager, the interface that DB2 uses, can fully exploit this feature. This reduces
the amount of storage that DB2 requires below the 16 MB line.
This enhancement does not only provide virtual storage relief. It also removes a potential
scalability problem with growing systems and growing machine capacity.
In addition, DB2 V8 no longer uses system-generated DDNAMEs, as the current limit there is
also 32k. DB2 generates its own DDNAMEs for dynamic allocation. This way DB2 can have
better open data set performance as well, and, can avoid the problem of the task that
generates the system DDNAMEs becoming a bottleneck for parallel data set open.
When DSMAX is reached, DB2 currently attempts to close up to 3% of the open data sets.
However, 3% of 65,041 is still a large number, and this burst of data set close activity could be
disruptive. Therefore DB2 now closes MIN(3%,300) data sets when DSMAX is reached.
PFT UQ96862 for APAR PQ96189 is related to the number of open data sets.
4.13.3 SMF type 89 record collection enhancements
SMF type 89-1 interval records provide IBM with the required “Software Usage Report” for
reporting on zSeries Software License Requirements.
Prior to V8, DB2 automatically used detailed tracking of measured usage if SMF type 89
records were activated.
DB2 V8 provides a new DSNZPARM parameter, SMF89, which lets you specify whether DB2
is to do detailed tracking for measured usage pricing. The default value is NO, which means
that DB2 does not do detailed measured usage tracking. If the SMF type 89 record is
activated, only high-level tracking is recorded in the SMF type 89 record.
If you select YES, DB2 does detailed measured usage tracking if SMF type 89 records are
activated. When SMF89 is set to YES, DB2 invokes a z/OS service on every entry or exit into
or out of DB2 to ensure accurate tracking. A new SMF type 89 record is cut on each SQL
statement.
If you select NO, DB2 CPU is reduced; however, the amount of time spent in DB2 as
measured by SMF 89 is increased.
A "typical" CPU overhead for DB2 performing detailed tracking of CPU usage is in the range
of 0 to 5%. Since there is a fixed overhead per SQL statement, the overhead tends to be
higher for short-running SQL statements and negligible for long-running SQL statements. For
Chapter 4. DB2 subsystem performance 213