Recovery in DBMS
Recovery refers to the processes and mechanisms used to restore a database to a consistent state after a failure. Failures can be due to system crashes, power outages, hardware failures, or software bugs. The goal of recovery is to ensure that the database remains consistent and all transactions are completed correctly.
Methods of Recovery:
- Transaction Logging:
- Write-Ahead Logging (WAL): This technique ensures that all modifications are logged before they are actually written to the database. The log records all changes made by transactions and is used to redo or undo transactions in case of a failure.
- Checkpointing:
- Periodically, the database system takes a checkpoint, which is a snapshot of the database at a certain point in time. Checkpoints help to reduce the amount of work needed during recovery because only transactions after the last checkpoint need to be redone or undone.
Recovery Techniques:
- Deferred Update: Changes made by a transaction are not immediately written to the database. Instead, they are recorded in a log and only applied to the database when the transaction commits.
- Immediate Update: Changes are applied to the database as they occur, but logs are maintained to undo changes if a transaction fails.
- Shadow Paging: A technique that maintains two versions of the database: the current and the shadow (backup). Changes are made to the current version, and the shadow version remains unchanged until the transaction commits.
Types of Recovery:
- Crash Recovery: Restores the database to a consistent state after a system crash.
- Media Recovery: Involves restoring the database from backup files in case of hardware failures like disk crashes.
Atomicity in DBMS
Atomicity is one of the four ACID properties (Atomicity, Consistency, Isolation, Durability) that guarantee transaction reliability in a DBMS. Atomicity ensures that a transaction is treated as a single unit of work, which means either all of its operations are executed successfully, or none are.
- All-or-Nothing Principle:
- A transaction must be completed in its entirety or not at all. If any part of the transaction fails, the entire transaction must be rolled back, and no changes should be made to the database.
- Commit and Rollback:
- Commit: This operation finalizes a transaction, making all changes made by the transaction permanent in the database.
- Rollback: This operation undoes all changes made by a transaction if any part of it fails, restoring the database to its state before the transaction begins.
- Transaction States:
- Active: The transaction is currently executing.
- Partially Committed: The transaction has completed its final operation but is not yet committed.
- Failed: The transaction cannot proceed due to some error.
- Aborted: The transaction has been rolled back and terminated.
- Committed: The transaction has successfully completed and all changes are permanent.
Relationship Between Recovery and Atomicity
Recovery mechanisms ensure atomicity by making sure that transactions are either fully completed or fully undone. If a transaction fails, recovery procedures use logs and other techniques to roll back the incomplete transaction, thus maintaining the atomicity property. Checkpoints and logging are crucial for supporting both recovery and atomicity, as they provide the necessary data to restore the database to a consistent state and ensure that only fully completed transactions are reflected in the database.