Recoverability of Schedules in DBMS

Check Whether a Number is Prime or Not in Python

Recoverability of Schedules

In this article, we will learn about Recoverability of Schedules in DBMS. A schedule is recoverable if each transaction in the schedule commits only after all the transactions containing the changes it read commit.

Recoverability of Schedules in DBMS

Sometimes a transaction may not execute completely due to a software issue, system crash or hardware failure. In that case, the failed transaction has to be rollback. But some other transactions may also have used value produced by the failed transaction. So we also have to rollback those transactions. This process is called recoverability of schedules.

  • Different types of recoverability of schedules are
  • Recoverable Schedule
  • Cascadeless Schedule
  • Strict Schedule
  • Cascading Abort
recoverability of schedule

1.Recoverable Schedule:

  • A schedule is said to be recoverable if it is recoverable as name suggest i.e only reads are allowed before write operation on same data.
  • Only reads (Tm->Tn) is permissible.


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

  • Given schedule follows order of Tm->Tn => C1->C2.
  • Transaction T1 is executed before T2 hence there is no chance of conflict occur.
  • R1(x) appears before W1(x) and transaction T1 is committed before T2 i.e. completion of first transaction performed first update on data item x, hence given schedule is recoverable.

Recoverable schedules

Example of irrecoverable schedule:

S2: R1(x), R2(x), R1(z), R3(x), R3(y), W1(x), W3(y), R2(y), W2(z), W2(y), C1, C2, C3;

  • Tm->Tn => C2->C3 but W3(y) executed before W2(y) which leads to conflicts thus it must be committed before T2 transaction. So given schedule is unrecoverable.
  • If Tm->Tn => C3->C2 is given in schedule then it will become recoverable schedule.


A committed transaction should never be rollback. It means that reading value from uncommitted transaction and commit it will enter the current transaction into inconsistent or unrecoverable state this is called Dirty Read problem.

2. Cascadeless Schedule:

When no read or write-write occurs before execution of transaction then corresponding schedule is called cascadeless schedule.


S3: R1(x), R2(z), R3(x), R1(z), R2(y), R3(y), W1(x), C1, W2(z), W3(y), W2(y), C3, C2;

In this schedule W3(y) and W2(y) overwrite conflicts and there is no read, therefore given schedule is cascadeless schedule

Special Case

A committed transaction desired to abort. As given in image all the transactions are reading committed data, hence it is cascadeless schedule.

Cascadeless schedules

3. Strict Schedule

  • If the schedule contains no read or writes before commit then it is known as a strict schedule.
  • A strict schedule is strict in nature.


S4: R1(x), R2(x), R1(z), R3(x), R3(y), W1(x), C1, W3(y), C3, R2(y), W2(z), W2(y), C2;

In this schedule, no read-write or write-write conflict arises before commit hence it is a strict schedule

Strict schedules

4. Cascading Abort

  • Cascading Abort can also be rollback.
  • If transaction T1 abort as T2 read data that written by T1 which is not committed,therefore, it is cascading rollback.
Cascading Abort

Prime Course Trailer

Related Banners

Get PrepInsta Prime & get Access to all 200+ courses offered by PrepInsta in One Subscription

Get over 200+ course One Subscription

Courses like AI/ML, Cloud Computing, Ethical Hacking, C, C++, Java, Python, DSA (All Languages), Competitive Coding (All Languages), TCS, Infosys, Wipro, Amazon, DBMS, SQL and others

Checkout list of all the video courses in PrepInsta Prime Subscription

Checkout list of all the video courses in PrepInsta Prime Subscription