Recoverability in DBMS | Recoverable Schedule

Schedules in DBMS-

 

Before you go through this article, make sure that you have gone through the previous article on Schedules in DBMS.

 

We have discussed-

• A schedule is the order in which the operations of multiple transactions appear for execution.
• Non-serial schedules may be serializable or non-serializable.

 

 

In this article, we will discuss about Non-Serializable Schedules.

 

Also read- Serializability in DBMS

 

Non-Serializable Schedules-

 

• A non-serial schedule which is not serializable is called as a non-serializable schedule.
• A non-serializable schedule is not guaranteed to produce the the same effect as produced by some serial schedule on any consistent database.

 

Characteristics-

 

Non-serializable schedules-

• may or may not be consistent
• may or may not be recoverable

 

Irrecoverable Schedules-

 

If in a schedule,

• A transaction performs a dirty read operation from an uncommitted transaction
• And commits before the transaction from which it has read the value

then such a schedule is known as an Irrecoverable Schedule.

 

Example-

 

Consider the following schedule-

 

 

Here,

• T2 performs a dirty read operation.
• T2 commits before T1.
• T1 fails later and roll backs.
• The value that T2 read now stands to be incorrect.
• T2 can not recover since it has already committed.

 

Recoverable Schedules-

 

If in a schedule,

• A transaction performs a dirty read operation from an uncommitted transaction
• And its commit operation is delayed till the uncommitted transaction either commits or roll backs

then such a schedule is known as a Recoverable Schedule.

 

Here,

• The commit operation of the transaction that performs the dirty read is delayed.
• This ensures that it still has a chance to recover if the uncommitted transaction fails later.

 

Example-

 

Consider the following schedule-

 

 

Here,

• T2 performs a dirty read operation.
• The commit operation of T2 is delayed till T1 commits or roll backs.
• T1 commits later.
• T2 is now allowed to commit.
• In case, T1 would have failed, T2 has a chance to recover by rolling back.

 

Checking Whether a Schedule is Recoverable or Irrecoverable-

 

Method-01:

 

Check whether the given schedule is conflict serializable or not.

• If the given schedule is conflict serializable, then it is surely recoverable. Stop and report your answer.
• If the given schedule is not conflict serializable, then it may or may not be recoverable. Go and check using other methods.

 

Thumb Rules All conflict serializable schedules are recoverable. All recoverable schedules may or may not be conflict serializable.

 

Method-02:

 

Check if there exists any dirty read operation.

(Reading from an uncommitted transaction is called as a dirty read)

• If there does not exist any dirty read operation, then the schedule is surely recoverable. Stop and report your answer.
• If there exists any dirty read operation, then the schedule may or may not be recoverable.

 

If there exists a dirty read operation, then follow the following cases-

 

Case-01:

 

If the commit operation of the transaction performing the dirty read occurs before the commit or abort operation of the transaction which updated the value, then the schedule is irrecoverable.

 

Case-02:

 

If the commit operation of the transaction performing the dirty read is delayed till the commit or abort operation of the transaction which updated the value, then the schedule is recoverable.

 

Thumb Rule No dirty read means a recoverable schedule.

 

Next Article- Cascading Schedule | Cascading Rollback | Cascadeless Schedule

 

Get more notes and other study material of Database Management System (DBMS).

Watch video lectures by visiting our YouTube channel LearnVidFun.