Normal restart and recovery

Db2 uses its recovery log and the bootstrap data set (BSDS) to determine what to recover when restarting. The BSDS identifies the active and archive log data sets, the location of the most recent Db2 checkpoint on the log, and the high-level qualifier of the integrated catalog facility catalog name.

After Db2 is initialized, the restart process goes through four phases, which are described in the following sections:

• Phase 1: Log initialization
• Phase 2: Current status rebuild
• Phase 3: Forward log recovery
• Phase 4: Backward log recovery

The terms inflight, indoubt, in-commit, and in-abort refer to statuses of a unit of work that is coordinated between Db2 and another system, such as CICS®, IMS, or a remote DBMS. For definitions of those terms, see Consistency after termination or failure.

At the end of the fourth phase recovery, a checkpoint is taken and committed changes are reflected in the data.

Application programs that do not commit often enough cause long-running units of recovery (URs). These long-running URs might be inflight after a Db2 failure. Inflight URs can extend Db2 restart time. You can restart Db2 more quickly by postponing the backout of long-running URs. Installation options LIMIT BACKOUT and BACKOUT DURATION establish what work to delay during restart.

If your Db2 subsystem has the UR checkpoint count option enabled, Db2 generates console message DSNR035I and trace records for IFCID 0313 to inform you about long-running URs. The UR checkpoint count option is enabled at installation time, through field UR CHECK FREQ on panel DSNTIPL.

If your Db2 subsystem has the UR log threshold option enabled, Db2 generates console message DSNB260I when an inflight UR writes more than the installation-defined number of log records. Db2 also generates trace records for IFCID 0313 to inform you about these long-running URs. The UR log threshold option is established at installation time, through field UR LOG WRITE CHECK on panel DSNTIPL.

Restart of large object (LOB) table spaces is like restart of other table spaces. LOB table spaces that are defined with LOG NO do not log LOB data, but they log enough control information (and follow a force-at-commit policy) so that they can restart without loss of data integrity.

After Db2 has gone through a group or normal restart that involves group buffer pool (GBP) failure, group buffer pool recovery pending (GRECP) can be automatically initiated for all objects except the object that is explicitly deferred during restart (ZPARM defer), or the object that is associated with the indoubt or postponed-abort UR.