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

5.6.4 Improved LPL recovery
One source of unplanned outages that many DB2 customers have struggled with is LPL
(logical page list) pages. DB2 puts pages into the LPL typically when I/O or coupling facility
read or write errors are encountered. Once a page is entered into the LPL, that page is
inaccessible until it is recovered. LPL recovery can be done using:
► -START DATABASE command with SPACENAM option
► RECOVER utility
The -START DATABASE command drains the entire table space or partition, therefore making
the entire page set or partition unavailable for the duration of the LPL recovery process even if
only one page is in the LPL for that table space or partition. During the execution of the
recover utility the table space or partition is unavailable.
DB2 V8 always attempts to automatically recover the LPL pages at the time that the pages
are added to LPL. Those pages are deleted from the LPL when the automatic LPL recovery
completes successfully.
Even more important than automatic LPL recovery is that with DB2 V8, during LPL recovery,
all pages that are not in the LPL are accessible by SQL. Up to DB2 V7, the entire table space
or partition was unavailable during LPL recovery.
5.6.5 Partitioning key update enhancement
Some customers find the current implementation that allows update of values in partitioning
key columns unusable because it does not allow concurrency if an update of a partitioning
key changes the partition to which the row belongs.
If the update requires moving the data row from one partition to another, DB2 tries to take
exclusive control of the objects to perform the update by acquiring DRAIN locks. Because of
this, no other application can access the range of partitions affected by update of values in
partitioning key columns.
Description
Up to DB2 V7, DB2 takes the exclusive control to perform the partitioned key update on:
► The partition of the table space from which the row is moving, the partition of the table
space to which the row is moving, and all partitions in between,
► The partition of the partitioning index from which the partitioning key is moving, the
partition of the partitioning index to which the partitioning key is moving, and all partitions
in between
► Non partitioning indexes defined on the table space.
When updating values in columns that define the partitioning key, DB2 V8 will NOT take
exclusive control of the objects to perform the update.
If a row moves from one partition to another in a table that is a dependent table in a
Referential Integrity relationship, there is a possibility of missing the row when checking for RI.
To prevent this, if any update changes the row’s partition, a COMMIT duration S lock will be
acquired on the parent table rows.
Change to DSNZPARM parameter PARTKEYU
The existing system parameter PARTKEYU specifies whether values in columns that
participate in partitioning keys may be updated.
► “YES” - Values in such columns may be updated. This is the default value.
Chapter 5. Availability and capacity enhancements 257