Details of Fast Recovery After A Full Checkpoint

This section discusses fast recovery after a full checkpoint. (Also see Details of Fast Recovery After A Fuzzy Checkpoint.)

Fast recovery returns the database server to a consistent state as part of shared-memory initialization. The consistent state means that all committed transactions are restored, and all uncommitted transactions are rolled back.

Fast recovery is accomplished in the following two stages:

• The database server uses the physical log to return to the most recent point of known physical consistency, the most recent checkpoint.
• The database server uses the logical-log files to return to logical consistency by rolling forward all committed transactions that occurred after the last checkpoint and rolling back all transactions that were left incomplete.

Fast recovery occurs in the following steps:

1. Uses the data in the physical log to return all disk pages to their condition at the time of the most recent checkpoint.
2. Locates the most recent checkpoint record in the logical-log files.
3. Rolls forward all logical-log records written after the most recent checkpoint record.
4. Rolls back transactions that do not have an associated COMMIT or BEGCOM record in the logical log.

   The database server writes the BEGCOM record when a transaction commits. For details, see the chapter on logical-log records in the IBM Informix Administrator's Reference.

The paragraphs that follow describe each step in detail.

Returning to the Last-Checkpoint State

To accomplish the first step, returning all disk pages to their condition at the time of the most recent checkpoint, the database server writes the before-images stored in the physical log to shared memory and then back to disk. Each before-image in the physical log contains the address of a page that was updated after the checkpoint. When the database server writes each before-image page in the physical log to shared memory and then back to disk, changes to the database server data since the time of the most recent checkpoint are undone. Figure 63 illustrates this step.

The database server is now physically consistent.

Figure 63. Writing All Remaining Before-Images in the Physical Log Back to Disk

Finding the Checkpoint Record in the Logical Log

In the second step, the database server locates the address of the most recent checkpoint record in the logical log. The most recent checkpoint record is guaranteed to be in the logical log on disk.

Rolling Forward Logical-Log Records

The third step in fast recovery rolls forward the logical-log records that were written after the most recent checkpoint record. This action reproduces all changes to the databases since the time of the last checkpoint, up to the point at which the uncontrolled shutdown occurred. Figure 64 illustrates this step.

Figure 64. Rolling Forward the Logical-Log Records Written Since the Most Recent Checkpoint

Rolling Back Incomplete Transactions

The final step in fast recovery rolls back all logical-log records for transactions that were not committed at the time the system failed. All databases are logically consistent because all committed transactions are rolled forward and all uncommitted transactions are rolled back.

Transactions that have completed the first phase of a two-phase commit are exceptional cases. For more information, see How the Two-Phase Commit Protocol Handles Failures.

Because one or more transactions possibly spanned several checkpoints without being committed, this rollback procedure might read backward through the logical log past the most recent checkpoint record. All logical-log files that contain records for open transactions are available to the database server because a log file is not freed until all transactions that it contains are closed. Figure 65 illustrates the rollback procedure. When fast recovery is complete, the database server returns to quiescent, single-user, or online mode.

Figure 65. Rolling Back All Incomplete Transactions