Forward-log recovery

In the forward-log recovery phase, Db2 applies log records and completes any database write operations that were outstanding at the time of the failure.

It also rebuilds retained locks during this phase by reading that information from the log. Restart time is longer when lock information needs to be recovered during a group restart, because Db2 needs to go back to the earliest begin_UR for an inflight UR belonging to that subsystem. This is necessary to rebuild the locks that member has obtained during the inflight UR. (A normal restart goes back only as far as the earliest RBA that is needed for database writes or is associated with the begin_UR of indoubt units of recovery.)

If a problem exists that prevents an object's log record from being applied (for example, if the disk version of the data could not be allocated or opened), or if the page set is deferred, Db2 adds the relevant pages and page ranges to the logical page list. Only pages affected by the error are unavailable.

When each restarting member has completed its own forward-log recovery, it checks and waits for all members to finish. If there are non-starting members, peer forward-log recovery is performed.

During forward-log recovery, you see messages similar to the following messages:

 DSNR005I @DB3ADB2 RESTART...COUNTS AFTER FORWARD
 RECOVERY
 IN COMMIT=0, INDOUBT=0
 DSNR021I @DB3ADB2 DSNRRGRH DB2 SUBSYSTEM MUST PERFORM
 GROUP RESTART FOR PEER MEMBERS