Home » DBMS

Log-based Recovery in Database Management System

DBMS | Log-based Recovery: In this tutorial, we will learn about the log-based recovery and some modification technique in the database management system. By Prerana Jain Last updated : May 29, 2023

What is Log-based Recovery in DBMS?

A log is the most widely used recording database modification technique. The log is a structure used for recording database modification. It is a sequence of log record recording all the update activities in the database. We can use this log to recover from failure and to bring back the database to the consistent state. An update log record contains various fields:

• Transaction identifier: It is the identifier which uniquely identifies the transaction.
• Data item identifier: It is the identifier which uniquely identifies the data to be used.
• Old value: It is the value of the data item before the write operation.
• New value: It is the value of the data item after performing the write operation.
  There are many types of log record we denote the various types of log records:
  1. <Ti start> transaction Ti has started.
  2. <Ti, Xi, V1, V2> transaction Ti has performed a write on data item Xi, Xj has value v1 before the write and will have value V2 after the write operation.
  3. <Ti commit> transaction Ti has committed.
  4. <Ti abort> transaction Ti ha aborted.

Whenever a transaction performs write operation database is modified only when log record for that write is created. And logs may or may not contain the record of reading of data item. It is so because reading the data item does not affect the consistency of the database and is nowhere helpful in recovery mechanism.

Recovery Method Operations

In the recovery method, we use two operations:

1. Undo(Ti): Restores the values of all data item updated by transaction Ti to the old values.
2. Redo(Ti): Sets the value of all data item updated by transaction Ti to the new values. We need to undo a transaction T only when log contains the record <T start> only when log contains the record <start> and <T commit> both.

Database / Transaction Modification Techniques

There are mainly two techniques to ensure the transaction atomicity despite failure are as follow:

1. Immediate Database Modification

The immediate update technique allows database modification to output the database while the transaction is still in the active state. Data modification written by an active transaction is called uncommitted modification.

When a system crashes or a transaction fails, the old value of the data item should be used for bringing the database into the consistent state. This can be done by undoing operation. Before a transaction, Ti starts its execution the record <Ti start> is written to the log. During its execution and write(X) operation by Ti is preceded by the writing of the appropriate new update record to the log. When Ti partially commits, the record <Ti commit> is written to the log.

Example

<To start>
<To A, 1000, 950>
<To B, 2000, 2050>
<To commit>
<T1 start>
<T1 C, 700, 600>
<Ti commit>

We consider an example of banking system taken earlier for transaction To and T1 such that To is followed by T1. If the system crash occurs just after the log record and during recovery we do redo (To) and undo (T1) as we have both < To start > and <To commit> in the log record. But we do not have <T1 commit> with <T1 start> in log record. Undo(T1) should be done first then redo (To) should be done.

2. Deferred Modification Technique

Deferred database modification technique ensures transaction atomicity by recording all database modification in the log. In this technique, all the write statements of the transaction are applied to the database only when the transaction is partially committed. A transaction is said to be partially committed once the final action of the transaction has been executed.

When a transaction partially commits, then the information on the log associated with the transaction is used in executing the deferred writes. If the system crashes before the transaction completes its execution or if the transaction abort then the information on the log is ignored. Using the log the system can handle that result in the loss of information on volatile storage. The recovery scheme uses the procedure.

Redo(Ti) sets the value of all data item updated by transaction Ti to the new values. The set of data item updated by Ti and their respective new values can be found in the log. The redo transaction must be idempotent. That an executing it several times must be equivalent to executing it once.

After a failure, the recovery subsystem consults the log to determine which transaction need to to be redone. Transaction Ti is redone if and only if the log record contains both <Ti start> and <Ti commit> statements.

Example

(A)             (B)
<To start>     <To start>
<To A, 950>    <To A , 950>
<To B, 205>    <To B, 2050>
                <To commit>
                <T1 start>
                <T1 C, 600>

If a system fails just after the log record for the step write(B) of transaction To. The during recovery no redo operation will be done as we have only <To start> in log record but not <To commit>.

If a system crash occurs just after the log record write C. the during recovery only redo (To) is done as we have only <To start> and <To commit> in log disk. At the same time we have <T1 start> in log disk but not <T1 commit> so redo (T1) will not be done.

        (C)   
    <To start>
    <To A , 950>
    <To B, 2050>
    <To commit>
    <T1 start>
    <T1 C, 600>
    <T1 commit>

If a system crash occurs just after the log record <T1 commit> the during the recovery we will perform both redo (T0) and redo (TI) as we have both <To start> <To commit> and <T1 start>, <T1 commit> in log disk.