Database Recovery Techniques in DBMS

Database Systems like any other computer system, are subject to failures but the data stored in them must be available as and when required. When a database fails it must possess the facilities for fast recovery. It must also have atomicity i.e. either transactions are completed successfully and committed (the effect is recorded permanently in the database) or the transaction should have no effect on the database.

Types of Recovery Techniques in DBMS

Database recovery techniques are used in database management systems (DBMS) to restore a database to a consistent state after a failure or error has occurred. The main goal of recovery techniques is to ensure data integrity and consistency and prevent data loss.

There are mainly two types of recovery techniques used in DBMS

• Rollback/Undo Recovery Technique
• Commit/Redo Recovery Technique
• CheckPoint Recovery Technique

1. Rollback/Undo Recovery Technique

Rollback/Undo Recovery reverses the changes made by transactions that failed before completion. Using the transaction log, the system undoes these changes to restore the database to its previous consistent state.

2. Commit/Redo Recovery Technique

Commit/Redo Recovery re-applies the changes of successfully committed transactions after a system failure. It uses the transaction log to redo operations and restore the database to its most recent consistent state.

3. Checkpoint Recovery Technique

Checkpoint Recovery is a method used in databases to save the system’s state at regular intervals, called checkpoints. This saved state allows the system to recover quickly after a crash by restoring from the last checkpoint, reducing data loss and downtime. It ensures data consistency while balancing system performance and recovery time.

Database Systems

Database recovery helps restore data after failures like system crashes, wrong commands, virus attacks, etc. Recovery relies on backups and system logs (a special file that tracks all transaction activities).

System Log Entries

• start_transaction(T): Transaction T begins.
• read_item(T, X): T reads item X.
• write_item(T, X, old, new): T changes X from old to new.
• commit(T): T finishes successfully; changes are saved.
• abort(T): T fails and stops.
• checkpoint: Marks a safe state where all previous transactions are committed and logs are saved.

Recovery Actions

• Undo: Roll back changes of failed transactions using log info (set values back to old_value).
• Redo: Reapply operations of committed transactions if not written to disk.

Recovery Techniques

1. Deferred Update (No-Undo/Redo)

• Changes are made only after commit.
• If a transaction fails before commit, nothing needs to be undone.
• After a crash, redo may be needed.

2. Immediate Update (Undo/Redo)

• Changes can happen before commit but must be logged first.
• On failure, undo uncommitted changes; redo committed ones.

Other Recovery Mechanisms

• Buffering/Caching: Data is updated in memory (cache) before writing to disk. Modified buffers are marked using a dirty bit.
• Shadow Paging: Maintains a copy (shadow) of the database pages. Updates are made to new pages, and changes become official only after commit.
• Backward Recovery (Undo/Rollback): Reverses changes made by failed or incomplete transactions.
• Forward Recovery (Redo/Roll Forward): Reapplies saved valid changes to restore the database after a crash.

Backup Techniques

There are different types of Backup Techniques. Some of them are listed below.

• Full Database Backup: A complete backup of the entire database, including all data, system metadata, and full text catalogs. It allows full restoration of the database at the time the backup was taken.
• Differential Backup: Captures only the data that has changed since the last full backup. It requires the last full backup to restore the database, followed by the latest differential backup.
• Transaction Log Backup: Backs up all changes recorded in the transaction log since the last log backup. It includes every transaction and allows recovery to a specific point in time even if the data files are lost—without losing any committed transactions.