Berkeley DB Reference Guide:
Transaction Protected Applications

PrevRefNext

Recovery procedures

The fourth component of the infrastructure, recovery procedures, concerns the recoverability of the database. After any application or system failure, there are two possible approaches to database recovery.

  1. There is no need for recoverability, and all databases can be recreated from scratch, therefore the database home directory can simply be removed and recreated.

  2. It is necessary to recover information after system or application failure. Recovery (using the db_recover utility, or the DB_RECOVER or DB_RECOVER_FATAL flags to DBENV->open) must be performed on each Berkeley DB application environment, that is, each database home directory.

Performing recovery will remove all the shared regions (which may have been corrupted by the failure), establish the end of the log by identifying the last record written to the log, and then perform transaction recovery. Database applications must not be restarted until recovery completes. During recovery, all changes made by aborted or unfinished transactions are undone and all changes made by committed transactions are redone, as necessary. After recovery runs, the environment is properly initialized so that applications may be restarted. Any time an application crashes or the system fails, recovery processing should be performed on any database environments that were active at that time.

Additionally, there are two forms of recovery:

  1. catastrophic recovery. The Berkeley DB package defines catastrophic failure to be failure where either the database or log files have been destroyed or corrupted. For example, catastrophic failure includes the case where the disk drive on which either the database or logs are stored has been physically destroyed, or when the system's normal filesystem recovery on startup is unable to bring the database and log files to a consistent state.

    If the failure is catastrophic, a snapshot of the database files and the archived log files must be restored onto the system. Then the recovery process will review the logs and database files to bring the database to a consistent state as of the time of the last archived log file. Only transactions committed before that date will appear in the database.

  2. normal or non-catastrophic recovery. If the failure is non-catastrophic, i.e., the database files and log are accessible on a filesystem that has recovered cleanly, the recovery process will review the logs and database files to ensure that all committed transactions appear and that all uncommitted transactions are undone.

Recovery process

The recovery process works as follows:

First, find the last checkpoint that completed. Since the system may have crashed while writing a checkpoint, this implies finding the second-to-last checkpoint in the log files. Read forward from this checkpoint, opening any database files for which modifications are found in the log.

Then, read backward from the end of the log. For each commit record encountered, record its transaction ID. For every other data update record, find the transaction ID of the record. If that transaction ID appears in the list of committed transactions, do nothing; if it does not appear in the committed list, then call the appropriate recovery routine to undo the operation.

In the case of catastrophic recovery, this roll-backward pass continues through all the present log files. In the case of normal recovery, this pass continues until we find a checkpoint written before the second-to-last checkpoint described above.

When the roll-backward pass is complete, the roll-forward pass begins at the point where the roll-backward pass ended. Each record is read and if its transaction id is in the committed list, then the appropriate recovery routine is called to redo the operation if necessary.

In a distributed transaction environment, there may be transactions that are prepared, but not yet committed. If these transactions are XA transactions, then they are rolled forward to their current state, and an active transaction corresponding to it is entered in the transaction table so that the XA transaction manager may call either transaction abort or commit, depending on the outcome of the overall transaction. If the transaction is not an XA transaction, then it is aborted like any other transactions would be.

PrevRefNext

Copyright Sleepycat Software