Database Recovery Services for DB2 LUW
Objective: Implement database recovery solutions with DB2 for Linux, UNIX, and Windows.
The DB2 for Linux, Unix, and Windows Recovery Services engagement is designed to provide your
organization with customized assistance and skills transfer with advanced database recovery solutions with DB2 for Linux, Unix, and Windows.
This service engagement involves assistance with implementing customized scripts or procedures to
automate and manage all aspects of DB2 for LUW recovery. This typically includes procedures to automate
database backups, log archiving, database recovery, log retrieval, and roll-forward processing.
Advanced Database Recovery refers to the implementation of customized scripts or procedures to automate
and manage all aspects of DB2 recovery. These typically include backup, log archival, recovery, and roll
-forward processing in what is typically termed a "Roll Forward Recovery with Off-line Log Archival" recovery
environment. Off-line Log Archival provides for roll forward recovery in the event of a device or total system
failure, as the database transaction logs are moved from the database transaction log path and onto another device or system.
DB2 provides three methods for database recovery. These are crash recovery, restore recovery, and roll
forward recovery. Crash recovery is a method of recovery that attempts to resynchronize the database files
with the database transaction log files in the event that the database is left in an otherwise inconsistent and
unusable state. DB2 supports crash recovery right out of the box and by default it takes place automatically
without manual intervention. Restore recovery is a method of recovery that attempts to restore an image of
the database that was taken with the backup utility at a specific point in time. Finally roll forward recovery or
point-in-time recovery is a method of recovery that attempts to reapply transactions to the database image
after restore recovery has taken place. In order to support roll forward recovery you must change from circular logging to linear logging.
DB2 support two types of logging. Circular logging (as illustrated in the figure above) is the default setting. In
this implementation logs are recycled as soon as they are no longer needed for crash recovery. Linear
logging (as illustrated in the figure below) can easily be enabled by updating the database configuration
parameter called LOGRETAIN. Note that after this parameter has been updated and the database
deactivated you will need to take a complete off-line backup of the database before it can be accessed or
you will have to disable this parameter to access the database without taking a backup.
Once linear logging has been enabled, you can choose to optionally archive log files off-line (see illustration
below). Log archiving, the process of removing database transaction logs from the database server to a safer
place, has been supported by DB2 for close to a decade now. The concept is relatively simple, when the
database manager determinate that a log file is no longer needed it calls a user exit to archive the log. Once
the log has been successfully archived by the user exit program, the database manager simply reuses the
old log file by renaming it. The only minor detail that we left out is the user exit. Although IBM does provide
some very good sample programs in \IBM\SQLLIB\SAMPLES\USEREXIT\, it should be noted that the u in user exit means you get to write it.