Recoverability in DBMS

Recoverability is a critical feature of database systems. It ensures that after a failure, the database returns to a consistent state by permanently saving committed transactions and rolling back uncommitted ones. It relies on transaction logs to undo or redo changes as needed. This is crucial in multi-transaction environments to prevent cascading failures and maintain data integrity and consistency.

There are several levels of recoverability that can be supported by a database system:

• No-undo logging: This level of recoverability only guarantees that committed transactions are durable, but does not provide the ability to undo the effects of uncommitted transactions.
• Undo logging: This level of recoverability provides the ability to undo the effects of uncommitted transactions but may result in the loss of updates made by committed transactions that occur after the failed transaction.
• Redo logging: This level of recoverability provides the ability to redo the effects of committed transactions, ensuring that all committed updates are durable and can be recovered in the event of failure.
• Undo-redo logging: This level of recoverability provides both undo and redo capabilities, ensuring that the system can recover to a consistent state regardless of whether a transaction has been committed or not.

In addition to these levels of recoverability, database systems may also use techniques such as checkpointing and shadow paging to improve recovery performance and reduce the overhead associated with logging.

Overall, recoverability is a crucial property of database systems, as it ensures that data is consistent and durable even in the event of failures or errors. It is important for database administrators to understand the level of recoverability provided by their system and to configure it appropriately to meet their application's requirements.

Recoverable Schedules

A recoverable schedule in DBMS ensures that a transaction commits only after all transactions it depends on have committed. This prevents inconsistencies and ensures the database can recover correctly after failures. It maintains data integrity by avoiding scenarios where a committed transaction relies on an uncommitted or aborted one.

Example 1:

Consider the following schedule involving two transactions T₁ and T₂.

This is a recoverable schedule since T₁ commits before T₂, that makes the value read by T₂ correct.

Example 2:

S1: R1(x), W1(x), R2(x), R1(y), R2(y),W2(x), W1(y), C1, C2;

• T2 reads uncommitted data from T1 (R2(x) depends on W1(x)), but T2 commits only after T1 commits.
• The schedule is recoverable.

Read more about Types of Schedule Based on Recoverability.

Irrecoverable Schedules

An irrecoverable schedule occurs when a transaction commits after performing a dirty read—i.e., reading data written by another uncommitted transaction—and the original transaction later fails or is rolled back. This leads to inconsistency, as the committed transaction has used invalid data.

For example, if T2 reads and commits a value written by T1, but T1 later fails, the system cannot undo T2 since it has already committed. This makes the schedule irrecoverable. To avoid this, a transaction should not commit before the transactions it depends on have committed.

Recoverable with Cascading Rollback

A recoverable schedule with cascading rollback occurs when a failure in one transaction (Ti) causes other dependent transactions (Tj) to also roll back, but no committed transaction is affected. Since Tj reads data written by Ti and has not yet committed, it can be safely rolled back when Ti fails.

This preserves recoverability, as all dependencies commit in the correct order. Although multiple rollbacks may happen, the database remains consistent. Such a schedule follows the rule: Tj commits only after Ti commits.

Cascadeless Recoverable Rollback

A cascadeless recoverable schedule is a type of transaction schedule where transactions are both recoverable and free from cascading rollbacks. In this schedule, a transaction (Tj) reads data written by another transaction (Ti) only after Ti has committed.

This ensures that if Ti fails, no other transaction depends on its uncommitted changes, avoiding the need for cascading rollbacks. The schedule maintains consistency and simplifies recovery by preventing dirty reads. The key rule is: Tj reads Ti’s data only after Ti commits, ensuring both recoverability and cascadelessness.

Capabilities of Recoverability in DBMS

1. Atomicity: Transactions in a DBMS are atomic, meaning they either complete entirely or are rolled back to their original state in case of a failure. This ensures that the database remains in a consistent state at all times.
2. Durability: Once a transaction is committed, its changes are permanently saved to the database. Even in the event of a failure, these changes are retained, ensuring the database can be restored to its last consistent state.
3. Logging: A DBMS maintains a transaction log that records all changes made to the database and the transactions responsible for those changes. In case of a failure, this log is used to recover the database to a consistent state.
4. Checkpointing: Checkpoints mark a specific point in time where the DBMS saves the current state of the database. This reduces recovery time after a failure, as only the transactions occurring after the last checkpoint need to be rolled back or replayed.
5. Recovery Manager: The recovery manager is a component of the DBMS responsible for restoring the database to a consistent state after a failure. It uses logs and checkpoints to identify and handle transactions that need to be undone or redone.
6. Media Recovery: Media recovery deals with recovering the database from storage failures, such as a hard drive crash. This involves restoring the database from backups and using transaction logs to bring it up to date.