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

5.4 Volatile table
5.4.1 Conclusion
DB2 V6 introduced a new parameter, NPGTHRSH, which will cause the DB2 Optimizer to
favor index access for tables whose statistics indicate fewer than a given number of pages.
For a given table, if NPAGES is fewer than the NPGTHRSH value, index access for the table
will be preferred over a table space scan. After the initial install of ERP application packages,
there are many empty or small tables which could grow rapidly in size. There are also a
number of tables which are very volatile, meaning the number of rows can change very
quickly and in large amounts. If a RUNSTATS is run on these tables when they are small, the
DB2 optimizer would favor a table space scan, which would be inappropriate when the table
grows. Prior to this enhancement, the recommendation was to update the catalog statistics
for volatile tables.
DB2 V8 introduces the VOLATILE keyword on the CREATE and ALTER statements. A volatile
table is a table whose contents can vary from zero to very large at run time. DB2 often does a
table space scan or non-matching index scan when the data access statistics indicate that a
table is small, even though matching index access is possible. This is a problem if the table is
small or empty when statistics are collected, but the table is large when it is queried. In that
case, the statistics are not accurate and can lead DB2 to pick an inefficient access path.
Forcing index access may be desired for tables whose size can vary greatly.
In some applications, and often with SAP, a DB2 table, called a cluster table, can be made up
of logical rows, with each logical row consisting of multiple physical rows from that table. A
logical row is identified by the primary key with a “sequence number” appended to provide the
logical ordering of the physical rows. When accessing this type of table, the physical rows are
intended to be accessed in this order (primary key + sequence number). This reduces the
chance of deadlocks occurring when two applications attempt to lock the same logical row but
touch the underlying physical rows in a different order. This means that certain types of
access paths are disabled for these types of tables. They are: list prefetch hybrid join and
multi-index access.
Although volatile tables and the NPGTHRSH subsystem parameter both cause DB2 to favor
index access, they behave differently and have different granularities. NPGTHRSH favors
index access on a subsystem level when the number of pages drops below the threshold. The
NPGTHRSH subsystem parameter causes DB2 to prefer index access in all of these cases,
even when statistics are not accurate. Volatile tables are designated at the table level instead
of the subsystem level, which allows you to favor index access for specific tables and specific
queries because only those tables that are defined as volatile favor index access. Finally,
volatile tables differ from the NPGTHRSH subsystem parameter by further restricting the
types of access to preserve the access sequence that is provided by the primary key.
5.4.2 Recommendations
Use the VOLATILE keyword on the CREATE table statement instead of the NPGTHRSH
DSNZPARM parameter in order to favor index access for volatile and cluster tables at the
table level.
5.5 Index enhancements
With the table-controlled partitioning concept in DB2 V8, clustering, being partitioned, and
being the partitioning index are now separate concepts. When using table-controlled
partitioning, a table does not require a partitioning index, since the partitioning is based on
246 DB2 UDB for z/OS Version 8 Performance Topics