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

For dynamically prepared queries, DB2 does not choose an index in RBDP for an access
path.
► Alter an index VARCHAR columns to be non padded
Prior to DB2 V8, varying length columns in indexes are padded to the maximum length
specified by VARCHAR(length). DB2 V8 provides a new default index option NOT
PADDED. Varying length columns are no longer padded to the maximum length in index
keys and index-only access becomes available for VARCHAR data.
This enhancement could also reduce storage requirements since only the actual data is
stored and the index tree level could be reduced.
The index can be altered between PADDED and NOT PADDED but will be placed in
RBDP.
Note that DB2 V6 introduced the DSNZPARM RETVLCFK. This parameter controls the
ability of the Optimizer to use index-only access when processing VARCHAR columns that
are part of an index. However, when one of the columns in the SELECT list of the query is
retrieved from the index when using index-only access, the column is padded to the
maximum length, and the actual length of the variable length column is not provided.
Therefore, an application must be able to handle these “full-length” variable length
columns. DB2 V7 enhances this feature by allowing index-only access against variable
length columns in an index, even with RETVLCFK=NO, if no variable length column is
present in the SELECT list of the query. DB2 V8 supports true varying-length key columns
in an index. Varying-length columns are not padded to their maximum lengths.
Versioning
To support online schema evolution, DB2 has implemented a new architecture, called
versioning, to track object definitions at different times during its life by using versions.
Altering existing objects may result in a new format for tables, table spaces, or indexes which
indicates how the data should be stored and used. Since all the data for an object and its
image copies cannot be changed immediately to match the format of the latest version,
support for migrating the data over time in some cases is implemented by using versions of
tables and indexes. This allows data access, index access, recovery to current, and recovery
to a point-in-time while maximizing data availability.
Availability considerations
Today, when an index is in Rebuild Pending (RBDP), the optimizer is unaware of that and can
still pick that index during access path selection when you are executing a query.
In Version 8, DB2 will try to avoid using indexes in RBDP for dynamically prepared queries.
DB2 will bypass indexes in Rebuild Pending (index is ignored):
► For all DELETE processing
► For all non-unique indexes for UPDATEs and INSERTs
► A unique index in RBDP cannot be avoided for UPDATE or INSERT because DB2 needs
the index to be available to be able to enforce uniqueness.
The DB2 optimizer treats RBDP indexes as follows:
► Dynamic PREPARE:
– Indexes in RBDP are avoided.
► Cached statements:
– If the statement is cached, the PREPARE is bypassed. But if the index is used by the
statement that is cached, it is invalidated by the ALTER.
232 DB2 UDB for z/OS Version 8 Performance Topics