Phase 3: Forward log recovery

During the third restart phase, Db2 completes the processing for all committed changes and database write operations.

Db2 processing during phase 3 includes:

  • Making all database changes for each indoubt unit of recovery and locking the data to prevent access to it after restart
  • Making database changes for inflight and in-abort units of recovery
  • In the case of group restarts in which locks have been lost, acquiring locks to prevent access to data that is in use by those units of recovery

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.)

Db2 executes these steps:

  1. Db2 detects whether a page set that is being recovered is at the same level ID as it was when the page set was last closed. If it is not, Db2 issues message DSNB232I and places the pages for that object on the logical page list (LPL). Db2 does not restart that object. In this case, you must recover from the down-level page set by using one of the methods described in Recovering from a down-level page set problem .
  2. Db2 scans the log forward, beginning at the lowest (earliest) log RBA that is either required for completion of database writes or that is associated with the Begin Unit of Recovery of units of recovery that require locks.

    That log RBA is determined during phase 2. REDO log records for all units of recovery are processed in this phase.

  3. Db2 uses the log RBA of the earliest potential REDO log record for each object (determined during phase 2). All earlier changes to the object have been written to disk; therefore, Db2 ignores their log records.
  4. Db2 reads the data or index page for each remaining REDO log record. The page header registers the log RBA of the record of the last change to the page.
    • If the log RBA of the page header is greater than or equal to that of the current log record, the logged change has already been made and written to disk, and the log record is ignored.
    • If the log RBA in the page header is less than that of the current log record, the change has not been made; Db2 makes the change to the page in the buffer pool.
  5. Db2 writes pages to disk as the need for buffers demands it.
  6. Db2 marks the completion of each unit of recovery that is processed. If restart processing terminates later, those units of recovery do not reappear in status lists.
  7. Db2 stops scanning at the current end of the log.
  8. Db2 writes to disk all modified buffers that are not yet written.
  9. Db2 issues message DSNR005I, which summarizes the number of remaining in-commit or indoubt units of recovery. No in-commit units of recovery should exist because all processing for these units should have completed. The number of indoubt units of recovery should be equal to the number that is specified in the previous DSNR004I restart message.
  10. Db2 issues message DSNR007I, which identifies any outstanding unit of recovery that still must be processed.

If Db2 encounters a problem while applying log records to an object during phase 3, the affected pages are placed in the logical page list. Message DSNI001I is issued once per page set or partition, and message DSNB250E is issued once per page. Restart processing continues.

Db2 issues status message DSNR031I periodically during this phase.