Home | Previous Page | Next Page   Logging and Log Administration > Checkpoints and Fast Recovery > Fast Recovery >

Details of Fast Recovery After A Fuzzy Checkpoint

This section discusses fast recovery after a fuzzy checkpoint. Fast recovery is accomplished in the following stages:

These stages can also be expressed as the following steps, which are described in detail in the paragraphs that follow:

  1. Use the data in the physical log to return disk pages for nonfuzzy operations to their condition at the time of the most recent checkpoint.
  2. Locate the oldest update in the logical-log that is not yet flushed to disk.
  3. Apply the log records for fuzzy operations that occurred before the most recent checkpoint.
  4. Roll forward all logical-log records written after the most recent checkpoint record.
  5. Roll back transactions that do not have an associated COMMIT or BEGIN COMMIT record in the logical log.

Although fast recovery after a fuzzy checkpoint takes longer than after a full checkpoint, you can optimize it. For details, see your IBM Informix: Performance Guide.

Returning to the Last-Checkpoint State for Nonfuzzy Operations

To accomplish the first step, returning all disk pages for nonfuzzy operations 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 96 illustrates this step.

Figure 96. Writing Nonfuzzy Before-Images in the Physical Log Back to Disk
begin figure description - This figure is described in the surrounding text. - end figure description

Pages on which fuzzy operations occurred are not physically consistent because the database server does not physically log their before-images. If the most recent checkpoint was a fuzzy checkpoint, the changed pages for fuzzy operations were not flushed to disk. The dbspace disk still contains the before-image of each page. To undo changes to these pages prior to the fuzzy checkpoint, the database server uses the logical log, as the next step describes.

Locating the Oldest Update in the Logical Log

In this step of fast recovery, the database server locates the oldest update record in the logical log that was not flushed to disk during the most recent checkpoint. The database server uses the log sequence numbers (LSN) in the logical log to find the oldest update record. The database server no longer starts fast recovery at the most recent checkpoint record.

Figure 97 shows that the oldest update in the logical log occurred several checkpoints ago and that all the log records are applied.

Figure 97. Locating the Oldest Update Record in the Logical Log
begin figure description - This figure is described in the surrounding text. - end figure description

You cannot free the logical log that contains the oldest update record until after the changes are recorded on disk. The database server automatically performs a full checkpoint to prevent problems with fast recovery of very old log records.

Applying the Log Records for Fuzzy Operations

In the second step, the database server processes the log records for fuzzy operations that occurred following the oldest update and before the last checkpoint. The log records that represent changes to data must be on disk before the changed data replaces the previous version on disk.

Log records for fuzzy operations are selectively redone, depending on whether the update has already been applied to the page. If the time stamp in the logical-log record is older than the time stamp in the disk page, the database server applies the record. Otherwise, the database server skips that record.

Figure 98 illustrates how the database server processes fuzzy records only prior to checkpoint.

Figure 98. Applying the Log Records for Fuzzy Operations
begin figure description - This figure is described in the surrounding text. - end figure description

Rolling Forward Logical-Log Records

In the third step, the database server processes all logical-log records following the last checkpoint. 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 99 illustrates the roll forward of all records after the fuzzy checkpoint.

Figure 99. Rolling Forward the Logical-Log Records Written Since the Most Recent Fuzzy Checkpoint
begin figure description - This figure is described in the surrounding text. - end figure description

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 that the system failed. This rollback procedure ensures that all databases are left in a consistent state.

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 contained within it are closed. Figure 100 illustrates the rollback procedure. When fast recovery is complete, the database server goes to quiescent or online mode.

Figure 100. Rolling Back All Incomplete Transactions
begin figure description - This figure is described in the surrounding text. - end figure description
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]