Recovery System

Chittaranjan Pradhan

Database Management Recovery System

Transaction Failure

System 23 Database Recovery

Shadow-Copy Scheme

Recovery System Recovery Facilities

Log-Based Recovery
Deferred Database
Modification
Immediate Database
Modification
Checkpoints

Chittaranjan Pradhan
School of Computer Engineering,
KIIT University
23.1
 Recovery System
Recovery System
Chittaranjan Pradhan

Recovery System

Transaction Failure

Recovery System Database Recovery

Shadow-Copy Scheme
The recovery manager of a database system is responsible for Recovery Facilities
ensuring two important properties of transactions: Log-Based Recovery
Deferred Database
• atomicity Modification
Immediate Database
Modification
• durability Checkpoints

It ensures the atomicity by undoing the actions of transactions

that do not commit

It ensures the durability by making sure that all actions of

committed transactions survive in case of system crashes and
media failures

23.2
 Recovery System
Transaction Failure
Chittaranjan Pradhan

Transaction Failure
Recovery System

• Transaction failure: Transaction Failure

Database Recovery
• Logical error : The transaction can not complete due to
Shadow-Copy Scheme
some internal error conditions, such as wrong input, data
Recovery Facilities
not found, overflow or resource limit exceeded Log-Based Recovery
• System error : The transaction can not complete because of Deferred Database
Modification
the undesirable state. However, the transaction can be Immediate Database
Modification
re-executed at a later time Checkpoints

• System crash: Power failure or other hardware or

software failure causes the system to crash. This causes
the loss of content of volatile storage and brings
transaction processing to a halt. But, the content of
nonvolatile storage remains intact and is not corrupted
• Disk failure: A disk block loses its content as a result of
either a head crash or failure during a data transfer
operation. Copies of the data on other disks are used to
recover from the failure

23.3
 Recovery System
Database Recovery
Chittaranjan Pradhan

Database Recovery Recovery System

Transaction Failure
Database recovery is the process of restoring a database to
Database Recovery
the correct state in the event of a failure Shadow-Copy Scheme

Recovery Facilities
This service is provided by the database system to ensure that Log-Based Recovery

the database is reliable and remains in consistent state in case Deferred Database
Modification

of a failure Immediate Database

Modification
Checkpoints

The recovery algorithms, which ensure database consistency

and transaction atomicity, consist of two parts:
• Actions taken during normal transaction processing to
ensure that enough information exists to allow recovery
from failures
• Actions taken after a failure to recover the database
contents to a state that ensures database consistency,
transaction atomicity and durability

23.4
 Recovery System
Shadow-Copy Scheme
Chittaranjan Pradhan
Shadow-Copy Scheme
This scheme is based on making copies of the database called Recovery System

shadow copies and it assumes that only one transaction is Transaction Failure

Database Recovery
active at a time
Shadow-Copy Scheme
This scheme assumes that the database is simply a file on
Recovery Facilities
disk. A pointer called db-pointer is maintained on disk; it points Log-Based Recovery
to the current copy of the database Deferred Database
Modification
Immediate Database
Modification
Checkpoints

Unfortunately, this implementation is extremely inefficient in the

context of large database, since executing a single transaction
requires copying the entire database. Also, the implementation
does not allow transactions to execute concurrently with one
another. Thus, this cannott be used for efficient recovery 23.5
 Recovery System
Recovery Facilities
Chittaranjan Pradhan

Recovery System

Transaction Failure
Recovery Facilities Database Recovery

Shadow-Copy Scheme
A database system should provide the following facilities to
Recovery Facilities
assist with the recovery: Log-Based Recovery

• Backup Mechanism: It makes periodic backup copies of Deferred Database

Modification

the database Immediate Database

Modification
Checkpoints
• Logging Facility: It keeps track of the current state of
transactions and the database modifications
• Checkpoint Facility: It enables updates to the database
that are in progress to be made permanent
• Recovery Management: It allows the system to restore
the database to a consistent state following a failure

23.6
 Recovery System
Log-Based Recovery
Chittaranjan Pradhan

Log-Based Recovery Recovery System

Transaction Failure
Log is a sequence of log records, recording all the update Database Recovery
activities in the database. It is kept on stable storage Shadow-Copy Scheme

Recovery Facilities

There are several types of log records. An update log record Log-Based Recovery
Deferred Database
describes a single database write. It has the following fields: Modification
Immediate Database

• Transaction Identifier: This is the unique identifier of the Modification

Checkpoints

transaction that performed the write operation

• Data-item Identifier: This is the unique identifier of the
data item written. Typically, it is the location on disk of the
data item
• Old Value: This is the value of the data item prior to the
write operation
• New Value: This is the value that the data item will have
after the write operation

23.7
 Recovery System
Log-Based Recovery...
Chittaranjan Pradhan

Log-Based Recovery... Recovery System

Various types of log records are: Transaction Failure

Database Recovery
• <Ti start>: Transaction Ti has started Shadow-Copy Scheme

• <Ti , xj ,v1 ,v2 >: Transaction Ti has performed a write Recovery Facilities

operation on the data item xj . This data item xj had value Log-Based Recovery
Deferred Database
v1 before the write, and will have value v2 after the write Modification
Immediate Database
Modification
• <Ti commit>: Transaction Ti has committed Checkpoints

• <Ti abort>: Transaction Ti has aborted

When a transaction performs a write operation, it is essential
that the log record for that write be created before the database
is modified

For log records to be useful for recovery from system and disk
failures, the log must reside in stable storage

The log contains a complete record of all database activities

23.8
 Recovery System
Deferred Database Modification
Chittaranjan Pradhan

Recovery System
Deferred Database Modification Transaction Failure

This scheme ensures transaction atomicity by recording all the Database Recovery

database modifications in the log, but deferring the execution of Shadow-Copy Scheme

Recovery Facilities
all write operations of a transaction until the transaction
Log-Based Recovery
partially commits Deferred Database
Modification
Immediate Database
Modification
The execution of transaction Ti proceeds as follows: Checkpoints

• Before Ti starts its execution, a record <Ti start> is written

to the log
• A write(X) operation by Ti results in the writing of a new
record to the log as <Ti , X, V>, where V is the new value
of X. For this scheme, the old value is not required
• When Ti partially commits, a record <Ti commit> is written
to the log

23.9
 Recovery System
Deferred Database Modification...
Chittaranjan Pradhan
T1 T2
Read(A); Read(C);
Recovery System
A:=A-100; C:=C-100;
Transaction Failure
Write(A); Write(C);
Database Recovery
Read(B);
Shadow-Copy Scheme
B:=B+100;
Recovery Facilities
Write(B);
Log-Based Recovery
Deferred Database
Suppose the transactions are executed serially in the order T1 Modification
Immediate Database
followed by T2 ; and the initial values of accounts A, B and C Modification
Checkpoints
before the execution took place were $1000, $2000 and $3000
respectively
Database Log
<T1 start>
<T1 ,A,900>
<T1 ,B,2100>
<T1 commit>
<T2 start>
<T2 ,C, 2900>
<T2 commit>

The values of different data items are changed in the database

only after their corresponding log records have been updated
in the log 23.10
 Recovery System
Deferred Database Modification...
Chittaranjan Pradhan

Recovery System

Redo(Ti ): It sets the value of all data items updated by Transaction Failure

Database Recovery
transaction Ti to the new values. The set of data items updated
Shadow-Copy Scheme
by Ti and their respective new values can be found in the log
Recovery Facilities

Log-Based Recovery
The redo operation must be idempotent, i.e. executing it Deferred Database
Modification

several times must be equivalent to executing it once Immediate Database

Modification
Checkpoints

Transaction Ti needs to be redone iff the log contains both the

record <Ti start> and the record <Ti commit>

Thus, if the system crashes after the transaction completes its

execution, the recovery scheme uses the information in the log
to restore the system to a previous consistent state after the
transaction had completed

23.11
 Recovery System
Deferred Database Modification...
Chittaranjan Pradhan

Case-1: Crash occurs just before <T1 commit>

Recovery System

Transaction Failure
Database Log
<T1 start> Database Recovery

<T1 ,A,900> Shadow-Copy Scheme

<T1 ,B,2100> Recovery Facilities

Log-Based Recovery
When the system recovers, no redo actions need to be taken, Deferred Database
Modification

because no commit record appears in the log. The log records Immediate Database
Modification

of the incomplete transaction T1 can be deleted from the log Checkpoints

Case-2 Crash occurs just after <T1 commit>

Database Log
<T1 start>
<T1 ,A,900>
<T1 ,B,2100>
<T1 commit>

When the system recovers, the operation redo(T1 ) is

performed since the record <T1 commit> appears in the log
23.12
 Recovery System
Deferred Database Modification...
Chittaranjan Pradhan

Recovery System

Transaction Failure

Case-3: Crash occurs just before <T2 commit> Database Recovery

Shadow-Copy Scheme

Recovery Facilities
Database Log
<T1 start> Log-Based Recovery
Deferred Database
<T1 ,A,900> Modification
<T1 ,B,2100> Immediate Database
Modification
<T1 commit> Checkpoints
<T2 start>
<T2 ,C, 2900>

When the system recovers, the operation redo(T1 ) is

performed since the record <T1 commit> appears in the log.
The log records of the incomplete transaction T2 can be
deleted from the log

23.13
 Recovery System
Deferred Database Modification...
Chittaranjan Pradhan

Recovery System

Transaction Failure
Case-4: Crash occurs just after <T2 commit> Database Recovery

Shadow-Copy Scheme

Database Log Recovery Facilities

<T1 start> Log-Based Recovery
<T1 ,A,900> Deferred Database
Modification
<T1 ,B,2100> Immediate Database
<T1 commit> Modification

<T2 start> Checkpoints

<T2 ,C, 2900>

<T2 commit>

When the system recovers, two commit records are found in

the log. Thus, the system must perform operations redo(T1 )
and redo(T2 ) in the order in which their commit records appear
in the log

23.14
 Recovery System
Immediate Database Modification
Chittaranjan Pradhan
Immediate Database Modification
This scheme allows database modifications to be output to the Recovery System

database while the transaction is still in the active state. Data Transaction Failure

modifications written by active transactions are called Database Recovery

uncommitted modifications Shadow-Copy Scheme

Recovery Facilities

Log-Based Recovery
In the event of a crash or a transaction failure, the system must Deferred Database
Modification
use the old-value field of the log records to restore the modified Immediate Database
Modification
data items to the value they had prior to the start of the Checkpoints

transaction. The undo operation accomplishes this restoration

The execution of transaction Ti proceeds as follows:

• Before Ti starts its execution, the system writes the record
<Ti start> to the log
• During its execution, any write(X) operation by Ti is
preceded by the writing of the appropriate new update
record to the log
• When Ti partially commits, the system writes the record
<Ti commit> to the log
23.15
 Recovery System
Immediate Database Modification...
Chittaranjan Pradhan

Database Log
<T1 start> Recovery System
<T1 ,A,1000,900> Transaction Failure
<T1 ,B,2000,2100> Database Recovery
<T1 commit>
Shadow-Copy Scheme
<T2 start>
Recovery Facilities
<T2 ,C, 3000,2900>
Log-Based Recovery
<T2 commit> Deferred Database
Modification
Immediate Database
The recovery scheme uses two recovery procedures: Modification
Checkpoints

• Undo(Ti ): It restores the value of all data items updated by

transaction Ti to the old values
• Redo(Ti ): It sets the value of all data items updated by
transaction Ti to the new values
The undo and redo operations must be idempotent

Transaction Ti needs to be undone if the log contains the

record <Ti start>, but doesn’t contain the record <Ti commit>

Transaction Ti needs to be redone if the log contains both the

record <Ti start> and the record <Ti commit> 23.16
 Recovery System
Immediate Database Modification...
Chittaranjan Pradhan

Case-1: Crash occurs just before <T1 commit>

Recovery System

Transaction Failure
Database Log
<T1 start> Database Recovery
<T1 ,A,1000,900>
Shadow-Copy Scheme
<T1 ,B,2000,2100>
Recovery Facilities

When the system recovers, it finds the record <T1 start> in the Log-Based Recovery
Deferred Database

log, but no corresponding <T1 commit> record. Thus, T1 must Modification

Immediate Database

be undone, so an undo(T1 ) is performed Modification

Checkpoints

Case-2 Crash occurs just after <T1 commit>

Database Log
<T1 start>
<T1 ,A,1000,900>
<T1 ,B,2000,2100>
<T1 commit>

When the system recovers, the operation redo(T1 ) must be

performed since the log contains both the record <T1 start>
and the record <T1 commit>
23.17
 Recovery System
Immediate Database Modification...
Chittaranjan Pradhan

Recovery System

Case-3: Crash occurs just before <T2 commit> Transaction Failure

Database Recovery

Shadow-Copy Scheme
Database Log
<T1 start> Recovery Facilities

<T1 ,A,1000,900> Log-Based Recovery

Deferred Database
<T1 ,B,2000,2100> Modification

<T1 commit> Immediate Database

Modification
<T2 start> Checkpoints

<T2 ,C, 3000, 2900>

When the system recovers, two recovery actions need to be

taken. The undo(T2 ) must be performed, because the record
<T2 start> appears in the log, but there is no record <T2
commit>. The operation redo(T1 ) must be performed since the
log contains both the record <T1 start> and the record <T1
commit>

23.18
 Recovery System
Immediate Database Modification...
Chittaranjan Pradhan

Recovery System

Transaction Failure

Case-4: Crash occurs just after <T2 commit> Database Recovery

Shadow-Copy Scheme

Database Log Recovery Facilities

<T1 start> Log-Based Recovery

Deferred Database
<T1 ,A,1000,900> Modification

<T1 ,B,2000,2100> Immediate Database

Modification
<T1 commit> Checkpoints

<T2 start>
<T2 ,C, 3000, 2900>
<T2 commit>

When the system recovers, both T1 and T2 need to be redone,

since the records <T1 start> and <T1 commit> appear in the
log, as do the records <T2 start> and <T2 commit>

23.19
 Recovery System
Checkpoints
Chittaranjan Pradhan

Checkpoints
Recovery System

When a system failure occurs, we must consult the log to Transaction Failure

determine those transactions that need to be redone and those Database Recovery

that need to be undone. For this, we need to search the entire Shadow-Copy Scheme

Recovery Facilities
log to determine this information. There are two major
Log-Based Recovery
difficulties with this approach: Deferred Database
Modification
• The search process is time consuming Immediate Database
Modification
Checkpoints
• Most of the transactions that need to be redone have
already written their updates into the database. Although
redoing them will cause no harm, it will nevertheless
cause recovery to take longer time
To reduce these types of overhead, checkpoints can be used
• Output onto stable storage all log records currently
residing in main memory
• Output to the disk all modified buffer blocks
• Output onto stable storage a log record <checkpoint>

23.20
 Recovery System
Checkpoints...
Chittaranjan Pradhan
While a checkpoint is in progress, transactions are not allowed
to perform any update actions such as writing to a buffer block
Recovery System
or writing a log record
Transaction Failure
After a failure has occurred, the recovery scheme examines Database Recovery
the log to determine the most recent transaction Ti that started Shadow-Copy Scheme
executing before the most recent checkpoint took place Recovery Facilities

• Scan backwards from end of log to find the most recent Log-Based Recovery
Deferred Database
<checkpoint> record Modification
Immediate Database
• Continue scanning backward till a record <Ti start> is Modification
Checkpoints
found
• Once the system has identified transaction Ti , the redo
and undo operations need to be applied to only
transaction Ti and all transactions Tj that started executing
after transaction Ti . Let these transactions are denoted by
the set T. The earlier part of the log can be ignored and
can be erased whenever desired
• For all transactions starting from Ti or later with no <Ti
commit> record in the log, execute undo(Ti )
• Scanning forward in the log, for all transactions starting
from Ti or later with a <Ti commit>, execute redo(Ti ) 23.21
 Recovery System
Checkpoints...
Chittaranjan Pradhan

Recovery System

Transaction Failure

Database Recovery

Shadow-Copy Scheme

Recovery Facilities

Log-Based Recovery
Deferred Database
Modification
Immediate Database
Modification
Checkpoints

• Transaction T1 has to be ignored

• Transactions T2 and T3 have to be redone
• T4 has to be undone
By taking checkpoints periodically, the DBMS can reduce the
amount of work to be done during restart in the event of a
subsequent crash
23.22