DBMS Menu

Recoverability in DBMS



Recoverability refers to the ability of a system to restore its state to a point where the integrity of its data is not compromised, especially after a failure or an error.

When multiple transactions are executing concurrently, issues may arise that affect the system's recoverability. The interaction between transactions, if not managed correctly, can result in scenarios where a transaction's effects cannot be undone, which would violate the system's integrity.

Importance of Recoverability:

The need for recoverability arises because databases are designed to ensure data reliability and consistency. If a system isn't recoverable:

  • The integrity of the data might be compromised.
  • Business processes can be adversely affected due to corrupted or inconsistent data.
  • The trust of end-users or businesses relying on the database will be diminished.

Levels of Recoverability

1. Recoverable Schedules

A schedule is said to be recoverable if, for any pair of transactions \(T_i\) and \(T_j\), if \(T_j\) reads a data item previously written by \(T_i\), then \(T_i\) must commit before \(T_j\) commits. If a transaction fails for any reason and needs to be rolled back, the system can recover without having to rollback other transactions that have read or used data written by the failed transaction.

Example of a Recoverable Schedule

Suppose we have two transactions \(T_1\) and \(T_2\).


| Transaction T1      | Transaction T_2     |
|---------------------|---------------------|
| Write(A)            |                     |
|                     | Read(A)             |
| Commit              |                     |
|                     | Write(B)            |
|                     | Commit              |

In the above schedule, \(T_2\) reads a value written by \(T_1\), but \(T_1\) commits before \(T_2\), making the schedule recoverable.


2. Non-Recoverable Schedules

A schedule is said to be non-recoverable (or irrecoverable) if there exists a pair of transactions \(T_i\) and \(T_j\) such that \(T_j\) reads a data item previously written by \(T_i\), but \(T_i\) has not committed yet and \(T_j\) commits before \(T_i\). If \(T_i\) fails and needs to be rolled back after \(T_j\) has committed, there's no straightforward way to roll back the effects of \(T_j\), leading to potential data inconsistency.

Example of a Non-Recoverable Schedule

Again, consider two transactions \(T_1\) and \(T_2\).


| Transaction T1      | Transaction T2      |
|---------------------|---------------------|
| Write(A)            |                     |
|                     | Read(A)             |
|                     | Write(B)            |
|                     | Commit              |
| Commit              |                     |

In this schedule, \(T_2\) reads a value written by \(T_1\) and commits before \(T_1\) does. If \(T_1\) encounters a failure and has to be rolled back after \(T_2\) has committed, we're left in a problematic situation since we cannot easily roll back \(T_2\), making the schedule non-recoverable.


3. Cascading Rollback

A cascading rollback occurs when the rollback of a single transaction causes one or more dependent transactions to be rolled back. This situation can arise when one transaction reads uncommitted changes of another transaction, and then the latter transaction fails and needs to be rolled back. Consequently, any transaction that has read the uncommitted changes of the failed transaction also needs to be rolled back, leading to a cascade effect.

Example of Cascading Rollback

Consider two transactions \(T_1\) and \(T_2\):


| Transaction T1      | Transaction T2      |
|---------------------|---------------------|
| Write(A)            |                     |
|                     | Read(A)             |
|                     | Write(B)            |
| Abort(some failure) |                     |
| Rollback            |                     |
|                     | Rollback (because it read uncommitted changes from T1)

Here, \(T_2\) reads an uncommitted value of A written by \(T_1\). When \(T_1\) fails and is rolled back, \(T_2\) also has to be rolled back, leading to a cascading rollback. This is undesirable because it wastes computational effort and can complicate recovery procedures.

4. Cascadeless Schedules

A schedule is considered cascadeless if transactions only read committed values. This means, in such a schedule, a transaction can read a value written by another transaction only after the latter has committed. Cascadeless schedules prevent cascading rollbacks.

Example of Cascadeless Schedule

Consider two transactions \(T_1\) and \(T_2\):


| Transaction T1      | Transaction T2      |
|---------------------|---------------------|
| Write(A)            |                     |
| Commit              |                     |
|                     | Read(A)             |
|                     | Write(B)            |
|                     | Commit              |

In this schedule, \(T_2\) reads the value of A only after \(T_1\) has committed. Thus, even if \(T_1\) were to fail before committing (not shown in this schedule), it would not affect \(T_2\). This means there's no risk of cascading rollback in this schedule.

Next Topic :Implementation of Isolation in DBMS