Normal restart and recovery for multiple systems

When Db2 acts together with another system, the recovery log contains information about units of recovery that are inflight, indoubt, in-abort, postponed-abort, or in-commit.

The phases of restart and recovery deal with that information as follows:

Phase 1: Log initialization

This phase proceeds as described in Phase 1: Log initialization.

Phase 2: Current status rebuild

While reading the log, Db2 identifies:

• The coordinator and all participants for every unit of recovery.
• All units of recovery that are outstanding and their statuses (indoubt, in-commit, in-abort, or inflight, as described under Consistency after termination or failure).

Phase 3: Forward log recovery

Db2 makes all database changes for each indoubt unit of recovery and locks the data to prevent access to it after restart. Later, when an indoubt unit of recovery is resolved, processing is completed in one of these ways:

• For the ABORT option of the RECOVER INDOUBT command, Db2 reads and processes the log, reversing all changes.
• For the COMMIT option of the RECOVER INDOUBT command, Db2 reads the log but does not process the records because all changes have been made.

At the end of this phase, indoubt activity is reflected in the database as though the decision was made to commit the activity, but the activity is not yet committed. The data is locked and cannot be used until Db2 recognizes and acts on the indoubt decision. (For a description of indoubt units of recovery, see Resolving indoubt units of recovery.)

Phase 4: Backward log recovery

This phase reverses changes that are performed for inflight or in-abort units of recovery. At the end of this phase, interrupted inflight and in-abort changes are removed from the database (the data is consistent and can be used) or removal of the changes is postponed (the data is inconsistent and unavailable).

If removal of the changes is postponed, the units of recovery become known as postponed-abort units of recovery. The data with pending backout work is in a restrictive state (restart pending) which makes the data unavailable. The data becomes available at completion of backout work or at cold start or conditional restart of Db2.

If the LIMIT BACKOUT system parameter is AUTO, completion of the backout work begins automatically by Db2 when the system accepts new work. If the LIMIT BACKOUT system parameter is YES, completion of the backout work begins when the RECOVER POSTPONED command is issued.