DDBMS - Database Recovery

DDBMS - Database Recovery

Database management systems turn to a number of recovery management methods in order to recover from database failure. We will review the various approaches to database recovery in this chapter.

Typical database recovery methods are −

• In the case of soft failures resulting in database inconsistency, the recovery plan involves absence or rolling back transactions. However, often, in order to return to a consistent transaction state, transaction redo may also be implemented.
• Recovery techniques involve restoring a previous copy of the database from archival backup in case of severe failures that result in significant damage to the database. A more up-to - date state of the database is obtained by redoing the committed transaction operations from the transaction log.

Recovery from Power Failure

Power loss causes information in the non-persistent memory to be lost. The operating system and the database management system restart when power is restored. The Recovery Manager initiates the transaction log recovery.

The recovery manager takes the following steps in the event of an immediate update mode-

The recovery manager takes the following steps in the case of a deferred update mode-

• The transactions in the successful list and in the failed list are undone and written on the list of abortion.
• Transactions specified in the before-commit list have been redone.
• For transactions in the commit or abort lists, no action is taken.
• On the abort list, transactions that are in the active list and failed list are written. No undo operations are needed because the changes have not yet been written to the disk.
• Transactions specified in the before-commit list have been redone.
• For transactions in the commit or abort lists, no action is taken.

Recovery from Disk Failure

A complete database loss is caused by a disk failure or hard crash. A new disk is prepared to recover from this hard crash, then the operating system is restored and eventually the database is recovered using the backup and transaction log of the database. For both immediate and delayed update modes, the recovery technique is the same.

The recovery manager takes the acts that follow-

• The commit list and before-commit list transactions are redone and are written to the commit list in the transaction log.
• In the transaction log, the transactions in the active list and the failed list are undone and written to the abort list.

Checkpointing

Checkpoint is the time that a record is written from the buffers into the database. As a result, the recovery manager would not have to redo the transactions that were committed prior to the checkpoint in the event of a system crash. Periodic checkpointing shortens the process of recovery.

The two types of techniques for checkpointing are-

• Consistent checkpointing
• Fuzzy checkpointing

Consistent Checkpointing

Consistent checkpointing produces at the checkpoint a consistent picture of the database. Only those transactions which are on the right side of the last checkpoint are undone or redone during recovery. Transactions are already committed on the left side of the last consistent checkpoint and do not need to be processed again. The checkpointing steps taken are −

• Active transactions are temporarily suspended.
• All main-memory buffer changes are written onto the disk.
• "In the transaction log, a" checkpoint "record is written.
• The log of transactions is written on the disk.
• The transactions that were suspended will be resumed.

If the transaction log is also archived in step 4, this checkpoint helps to recover from disk failures and power failures, otherwise it helps to recover from power failures only.

Fuzzy Checkpointing

In fuzzy checkpointing, all successful transactions are written into the log at the time of the checkpoint. The recovery manager processes only those transactions that were active during the checkpoint and later in the event of a power failure. The transactions that have been committed before checkpoint are written to the disk and therefore need not be redone.

Example of Checkpointing

Let us consider that tcheck is the time of checkpointing in the system and tfail is the time of system crash. Let there be four transactions Ta, Tb, Tc and Td such that −

• Ta commits before checkpoint.
• Tb starts before checkpoint and commits before system crash.
• Tc starts after checkpoint and commits before system crash.
• Td starts after checkpoint and was active at the time of system crash.

The situation is depicted in the following diagram −

The actions that are taken by the recovery manager are −

• Nothing is done with Ta.
• Transaction redo is performed for Tb and Tc.
• Transaction undo is performed for Td.

Transaction Recovery Using UNDO / REDO

Recovery of transactions is performed to remove the adverse effects of faulty transactions rather than to recover from a failure. Faulty transactions involve all transactions that have modified the database to an undesired state, and all transactions that have used faulty transaction-written values.

In these cases, transaction recovery is a two-step process-

• Both faulty transactions and transactions that could be affected by the faulty transactions are UNDO.
• All transactions that are not faulty but have been undone faulty transactions are REDO.

Steps for the UNDO operation are −

Steps for the REDO operation are −

• If INSERT has completed the faulty transaction, the recovery manager deletes the inserted data item(s).
• If DELETE has been completed for the faulty transaction, the recovery manager inserts the item(s) of the deleted data from the log.
• If a faulty UPDATE transaction has been completed, the Recovery Manager eliminates the value by entering the before-update value from the log.

• If INSERT is completed for the transaction, the Recovery Manager generates an insert from the log.
• If the DELETE transaction is completed, the Recovery Manager generates a log delete.
• If the UPDATE transaction has been completed, the Recovery Manager generates a log update.