Scribd
Upload
5 views4 pages

Database Recovery Techniques in DBMS

The document discusses different approaches for database recovery in distributed database management systems. It describes transaction undo/redo strategies for recovering from soft failures and restoring backups followed by redoing committed transactions from logs for hard failures. Checkpointing techniques like consistent and fuzzy checkpointing are also covered, which create consistent snapshots to shorten recovery by avoiding redoing committed transactions before the last checkpoint.

Uploaded by

Ahmad Fakhar
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views4 pages

Database Recovery Techniques in DBMS

The document discusses different approaches for database recovery in distributed database management systems. It describes transaction undo/redo strategies for recovering from soft failures and restoring backups followed by redoing committed transactions from logs for hard failures. Checkpointing techniques like consistent and fuzzy checkpointing are also covered, which create consistent snapshots to shorten recovery by avoiding redoing committed transactions before the last checkpoint.

Uploaded by

Ahmad Fakhar
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

6/6/23, 1:16 PM Distributed DBMS - Database Recovery

Distributed DBMS - Database Recovery

In order to recuperate from database failure, database management systems resort to a number of
recovery management techniques. In this chapter, we will study the different approaches for
database recovery.

The typical strategies for database recovery are −

In case of soft failures that result in inconsistency of database, recovery strategy includes
transaction undo or rollback. However, sometimes, transaction redo may also be adopted to
recover to a consistent state of the transaction.

In case of hard failures resulting in extensive damage to database, recovery strategies


encompass restoring a past copy of the database from archival backup. A more current state
of the database is obtained through redoing operations of committed transactions from
transaction log.

Recovery from Power Failure


Power failure causes loss of information in the non-persistent memory. When power is restored,
the operating system and the database management system restart. Recovery manager initiates
recovery from the transaction logs.

In case of immediate update mode, the recovery manager takes the following actions −

Transactions which are in active list and failed list are undone and written on the abort list.
Transactions which are in before-commit list are redone.

No action is taken for transactions in commit or abort lists.

In case of deferred update mode, the recovery manager takes the following actions −

Transactions which are in the active list and failed list are written onto the abort list. No undo
operations are required since the changes have not been written to the disk yet.

[Link] 1/4
6/6/23, 1:16 PM Distributed DBMS - Database Recovery

Transactions which are in before-commit list are redone.

No action is taken for transactions in commit or abort lists.

Recovery from Disk Failure


A disk failure or hard crash causes a total database loss. To recover from this hard crash, a new
disk is prepared, then the operating system is restored, and finally the database is recovered using
the database backup and transaction log. The recovery method is same for both immediate and
deferred update modes.

The recovery manager takes the following actions −

The transactions in the commit list and before-commit list are redone and written onto the
commit list in the transaction log.
The transactions in the active list and failed list are undone and written onto the abort list in
the transaction log.

Checkpointing
Checkpoint is a point of time at which a record is written onto the database from the buffers. As a
consequence, in case of a system crash, the recovery manager does not have to redo the
transactions that have been committed before checkpoint. Periodical checkpointing shortens the
recovery process.

The two types of checkpointing techniques are −

Consistent checkpointing
Fuzzy checkpointing

Consistent Checkpointing
Consistent checkpointing creates a consistent image of the database at checkpoint. During
recovery, only those transactions which are on the right side of the last checkpoint are undone or
redone. The transactions to the left side of the last consistent checkpoint are already committed
and needn’t be processed again. The actions taken for checkpointing are −

The active transactions are suspended temporarily.


All changes in main-memory buffers are written onto the disk.
A “checkpoint” record is written in the transaction log.
The transaction log is written to the disk.
[Link] 2/4
6/6/23, 1:16 PM Distributed DBMS - Database Recovery

The suspended transactions are resumed.

If in step 4, the transaction log is archived as well, then this checkpointing aids in recovery from
disk failures and power failures, otherwise it aids recovery from only power failures.

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

Example of Checkpointing
Let us consider that in system the time of checkpointing is tcheck and the time of system crash is
tfail. 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.

[Link] 3/4
6/6/23, 1:16 PM Distributed DBMS - Database Recovery

Transaction Recovery Using UNDO / REDO


Transaction recovery is done to eliminate the adverse effects of faulty transactions rather than to
recover from a failure. Faulty transactions include all transactions that have changed the database
into undesired state and the transactions that have used values written by the faulty transactions.

Transaction recovery in these cases is a two-step process −

UNDO all faulty transactions and transactions that may be affected by the faulty transactions.

REDO all transactions that are not faulty but have been undone due to the faulty transactions.

Steps for the UNDO operation are −

If the faulty transaction has done INSERT, the recovery manager deletes the data item(s)
inserted.

If the faulty transaction has done DELETE, the recovery manager inserts the deleted data
item(s) from the log.

If the faulty transaction has done UPDATE, the recovery manager eliminates the value by
writing the before-update value from the log.

Steps for the REDO operation are −

If the transaction has done INSERT, the recovery manager generates an insert from the log.

If the transaction has done DELETE, the recovery manager generates a delete from the log.

If the transaction has done UPDATE, the recovery manager generates an update from the log.

[Link] 4/4

Common questions

Powered by AI

Recovery techniques impact performance through resource consumption; transaction logging and checkpointing incur runtime overhead by ensuring state snapshots and recovery info. Increased storage for logs/checkpoints and CPU cycles for processing pre-emptive safety measures can elevate operational costs. Balancing these with reduced downtime justifies expenses by preventing data loss .

Transaction states are critical as they determine recovery actions post-failure. Active and failed transactions are undone, affecting database consistency. Handled through transaction logs, databases log checkpoints or abort transactions to maintain pre-failure consistency. Committed or pre-commit transactions are re-applied if needed, ensuring data integrity sustains over failures .

UNDO operations revert faulty transactions by reversing their effects: deleting inserted data, reinserting deleted items, and overwriting updated values with pre-update logs. REDO operations restore valid transactions impacted by faulty ones using logs to replicate insertions, deletions, or updates. These steps collectively revert undesirable changes while retaining intended database states post-recovery .

A combination of recovery techniques like UNDO/REDO operations, checkpointing, and use of transaction logs is preferred because each method addresses different failure aspects, ensuring comprehensive recovery. Soft errors need undo/redo, while hard failures require full database restoration. This synergy provides robust protection against diverse failure conditions, enhancing data integrity and minimizing downtime .

Transaction logs are crucial for recovery from disk failures, as they track transaction activity. Both immediate and deferred update modes use logs to redo committed transactions and write them to the commit list, while undoing and logging those in active and failed lists to the abort list. This ensures that all completed transactions are recovered, and incomplete transactions are aborted .

Checkpointing reduces recovery time by ensuring that only transactions after the last checkpoint are redone or undone, as earlier transactions are committed. Consistent checkpointing suspends active transactions, writes all buffer changes to disk, logs the checkpoint, and resumes transactions. Fuzzy checkpointing logs all active transactions during the checkpoint but only processes post-checkpoint and failure transactions during recovery .

Recovery management evolves by embracing scalable techniques fitting distributed databases' need for consistency across nodes. Techniques enhance concurrency control via timestamps or MVCC, shrinking recovery time and handling vast transaction logs efficiently, tailoring for cloud-based nodes. Exponential storage growth demands refining checkpoint/log management to sustain low-latency uninterrupted service .

During power failures, recovery mechanisms differ based on the update mode. In immediate update mode, the recovery manager undoes transactions in active and failed lists, writes them on the abort list, and redoes transactions in the before-commit list. In deferred update mode, it writes transactions in active and failed lists to the abort list with no undo operations, and redoes transactions in the before-commit list .

Distributed DBMSs use different strategies for database recovery depending on the type of failure. For soft failures, the system may use transaction undo or rollback to handle inconsistencies, or transaction redo to return to a consistent state. For hard failures, which involve extensive damage, the system restores the database using past backups and redoes operations of committed transactions to update to a current state .

Following a crash, the recovery sequence begins with checkpoint analysis. Transactions before a checkpoint are ignored if previously committed. Those spanning checkpoints need analysis: redo operations are applied if they committed post-checkpoint and undos for those active soon after the crash. This efficiently restores database state to pre-crash consistency .

You might also like