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

Volatile (or cluster) tables, used primarily by ERP vendors like SAP, are tables that
contain groups (or clusters) of rows which logically belong together. Within each
cluster, rows are meant to be accessed in the same sequence every time. Lock
contention occurs when DB2 chooses different access paths for different applications
operating on the same cluster table. In the absence of support for cluster tables in DB2,
users have to either change system-wide parameters that affect all tables, or change
statistics for each such table to ease the lock contention.
Cluster tables are referred to as volatile tables in DB2. Adding a new keyword,
VOLATILE, to the CREATE TABLE and ALTER TABLE statements signifies to DB2
which tables should be treated as volatile tables. For volatile tables, index access is
chosen whenever possible, regardless of the efficiency of the available indexes. That
is, a table scan is not chosen in preference to an inefficient index.
– CF lock propagation reduction
In a data sharing environment, this enhancement allows parent L-locks to be granted
locally without invoking global contention processing. Thereby, locking overhead due to
false contention is reduced. As a result, DB2 data sharing performance is enhanced.
Performance benefit varies depending on factors such as commit interval, thread
reuse, and number of tables accessed in a commit interval, if the SQL processing is
read-only or update.
– Several other lock enhancements, including overflow lock avoidance, skip uncommitted
inserts, and drain lock on partition key update.
► Instrumentation enhancements
DB2 V8 comes with numerous enhancements to the Instrumentation Facility Interface.
The most important are:
– Package level accounting
– Accounting roll-up for DDF and RRSAF threads
– Long-running reader tracking
– Lock escalation trace record
– Full SQL statement text trace record
– PREPARE attributes are also traced
– More high water marks in the statistics record
– Secondary authorization IDs via READS
– Storage 64-bit support as well as READS support
– Temporary space usage
– Auditing for multilevel security
– Option for EBCDIC or Unicode data
1.1.5 Migration changes
Migration is allowed exclusively from DB2 V7 subsystems. The migration SPE must have
been applied and started. The migration process has been changed and now consists of
three distinct steps or phases:
1. Compatibility mode (CM): This is the first phase, during which the user performs all the
tests needed to make sure all the applications run without problems with the new version.
Fallback to V7 in case of problems is allowed.
2. Enabling-new-function mode (ENFM): During this typically short (usually one hour)
second phase, the user converts the DB2 catalog and directory to a new format by using
online REORG executions. No fallback to DB2 V7 is allowed once this phase is entered.
3. New-function mode (NFM): This is the target third and final phase, where all new V8
functions are available.
8 DB2 UDB for z/OS Version 8 Performance Topics