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

All users requesting new access to the table space or partition are also suspended and must
wait until the recovery completes (or until the user times out). Therefore, the drain operation
can be very disruptive to other work that is running in the system, especially in the case
where only one or a few pages are in LPL.
In DB2 V8, the locking and serialization schemes in the -START DATABASE command have
changed when doing the LPL recovery. In prior versions of DB2, the -START DATABASE
command acquires a DRAIN ALL lock on the table space or partition when doing the LPL
recovery. DB2 V8 makes a WRITE CLAIM on the table space or partition. By acquiring a
WRITE CLAIM instead of a DRAIN ALL, the “good” pages can still be accessed by SQL while
the -START DATABASE is recovering the LPL pages. A new "LPL recovery” lock type is also
introduced to enforce that only one LPL recovery process is running at a time for a given table
space or partition.
This less disruptive locking strategy potentially enhances both the performance and
availability of your applications, as more data can potentially be available to the application
while the pages in the LPL are being recovered.
DB2 V8 also automatically attempts to recover pages that are added to the LPL at the time
they are added to the LPL, if DB2 determines that automatic recovery has a reasonable
chance of success. Automatic LPL recovery is not initiated by DB2 in the following situations:
► DASD I/O error
► During DB2 restart or end_restart time
► GBP structure failure
► GBP 100% loss of connectivity
Automatic LPL recovery improves the availability of your applications, as the pages in the LPL
can be recovered sooner. In many cases you do not have to issue the -START DATABASE
commands yourself to recover LPL pages.
In addition, DB2 V8 provides more detailed information in message DSNB250E why a page
has been added to the LPL. The different reason types are:
► DASD: DB2 encountered a DASD I/O error when trying to read or write pages on DASD.
► LOGAPPLY: DB2 cannot apply log records to the pages.
► GBP: DB2 cannot successfully read or write the pages from or to the group buffer pool due
to link or structure failure, GBP in rebuild, or GBP was disconnected.
► LOCK: DB2 cannot get the required page latch or page P-lock on the pages.
► CASTOUT: The DB2 Castout processor cannot successfully cast out the pages.
► MASSDEL: DB2 encountered an error in the mass delete processor during the phase 2 of
commit.
These extra diagnostics help you to quickly identify and hopefully resolve why pages are
being placed into the LPL thereby increasing the availability of your applications.
8.5.3 Restart Light enhancements
DB2 V7 introduced the concept of DB2 Restart Light which is intended to remove retained
locks with minimal disruption in the event of an MVS system failure. When a DB2 member is
started in restart light mode (LIGHT(YES)), DB2 comes up with a small storage footprint,
executes forward and backward restart log recovery, removes the retained locks, and then
self-terminates without accepting any new work.
Chapter 8. Data sharing enhancements 337