Chapter 5

Database Recovery Techniques

 Database Recovery

1 Purpose of Database Recovery

 To bring the database into the last consistent state, which existed prior to the
failure.

 To preserve transaction properties (Atomicity, Consistency, Isolation and

Durability).

Example:

 If the system crashes before a fund transfer transaction completes its

execution, then either one or both accounts may have incorrect value. Thus,
the database must be restored to the state before the transaction modified
any of the accounts.
Slide 2
 Database Recovery

2 Types of Failure

 The database may become unavailable for use due to

 Transaction failure: Transactions may fail because of

incorrect input, deadlock, incorrect synchronization.

 System failure: System may fail because of addressing

error, application error, operating system fault, RAM
failure, etc.

 Media failure: Disk head crash, power disruption, etc.

Slide 3
 Database Recovery
3 Transaction Log

 For recovery from any type of failure data values prior to modification
(BFIM - BeFore Image) and the new value after modification (AFIM –
AFter Image) are required.

 These values and other information is stored in a sequential file called

Transaction log. A sample log is given below.
P Operation Data item BFIM AFIM
Begin
Write X X = 100 X = 200
Begin
W Y Y = 50 Y = 100
R M M = 200 M = 200
R N N = 400 N = 400
End
Slide 4
 Database Recovery

4 Data Update

 Immediate Update: As soon as a data item is modified in cache, the disk

copy is updated.

 Deferred(Late) Update: All modified data items in the cache is written

either after a transaction ends its execution or after a fixed number of

transactions have completed their execution.

 Shadow update: The modified version of a data item does not overwrite

its disk copy but is written at a separate disk location.

 In-place update: The disk version of the data item is overwritten by the

cache version.
Slide 5
 Database Recovery

5 Data Caching

 Data items to be modified are first stored into database cache

by the Cache Manager (CM) and after modification, they are
flushed (written) to the disk.

 The flushing is controlled by dirty and Pin-Unpin bits.

 Dirty bits=1: Indicates that the data item is modified.

 Pin-Unpin bits: a page in cache is pinned (bit value=1) if it

can not be written back to disk as yet
Slide 6
 Database Recovery

6 Transaction Roll-back (Undo) and Roll-Forward (Redo)

 To maintain atomicity, a transaction’s operations are redone or

undone.

 Undo: Restore all BFIMs on to disk (Remove all AFIMs).

 Redo: Restore all AFIMs on to disk.

 Database recovery is achieved either by performing only Undos

or only Redos or by a combination of the two.

Slide 7
 Database Recovery

Write-Ahead Logging

 When in-place update (immediate or deferred) is used then log is necessary for
recovery and it must be available to recovery manager. This is achieved by
Write-Ahead Logging (WAL) protocol. WAL states that

 For Undo: Before a data item’s AFIM is flushed to the database disk
(overwriting the BFIM) its BFIM must be written to the log and the log
must be saved on a stable store (log disk).

 For Redo: Before a transaction executes its commit operation, all its
AFIMs must be written to the log and the log must be saved on a stable
store.
Slide 8
 Database Recovery
7 Check pointing
 Randomly or under some criteria, the database flushes its buffer to
database disk to minimize the task of recovery. The following steps
defines a checkpoint operation:
1. Suspend execution of transactions temporarily.

2. Force write modified buffer data to disk.

3. Write a [checkpoint] record to the log, save the log to disk.

4. Resume normal transaction execution.

 During recovery redo or undo is required to transactions appearing

after [checkpoint] record.
Slide 9
 Database Recovery

Steal/No-Steal and Force/No-Force

 Possible ways for flushing database cache to database disk:

1. Steal: Cache can be flushed before transaction commits.

 It avoids the need for a very large buffer space to store updated
pages in memory

2. No-Steal: Cache cannot be flushed before transaction commit.

3. Force: Cache is immediately flushed (forced) to disk(All pages

updated by a transaction are immediately written to disk when the
transaction commits).

Slide 10
 4. No-Force: An updated page of a committed transaction may still be in
the buffer when another transaction needs to update it

 This eliminate the I/O cost to read that page again from disk

 These give rise to four different ways for handling recovery:

 Steal/No-Force (Undo/Redo)

 Steal/Force (Undo/No-redo)

 No-Steal/No-Force (Redo/No-undo)

 No-Steal/Force (No-undo/No-redo)

Slide 11
 Database Recovery

8 Recovery Scheme
 Deferred Update (No Undo/Redo)

 The data update goes as follows:

 A set of transactions record their updates in the log.

 At commit point under WAL scheme, these updates are saved on

database disk.

 After reboot from a failure the log is used to redo all the transactions
affected by this failure. No undo is required because no AFIM is flushed
to the disk before a transaction commits.

Slide 12
Database Recovery
Deferred Update with concurrent users

 Two tables are required for implementing this protocol:

 Active table: All active transactions are entered in this table.

 Commit table: Transactions to be committed are entered in this table.

 During recovery, all transactions of the commit table are redone and all
transactions of active tables are ignored since none of their AFIMs
reached the database..

Slide 13
 Database Recovery

Recovery Techniques Based on Immediate Update

 Undo/No-redo Algorithm
 In this algorithm AFIMs of a transaction are flushed to
the database disk under WAL before it commits.

 For this reason the recovery manager undoes all

transactions during recovery.

 No transaction is redone.

Slide 14
 Database Recovery
Recovery Techniques Based on Immediate Update

 Undo/Redo Algorithm (Single-user environment)

 Recovery schemes of this category apply undo and also redo for recovery.

 In a single-user environment no concurrency control is required but a log is

maintained under WAL.

 Note that at any time there will be one transaction in the system and it will be
either in the commit table or in the active table.

 The recovery manager performs:

 Undo of a transaction if it is in the active table.

 Redo of a transaction if it is in the commit table.

Slide 15
 Database Recovery
Shadow Paging

 This recovery scheme does not require the use of a log in a single user
environment. The AFIM does not overwrite its BFIM but recorded at another
place on the disk. Thus, at any time a data item has AFIM and BFIM
(Shadow copy of the data item) at two different places on the disk.

X Y
X' Y'

Database

X and Y: Shadow copies of data items

X' and Y': Current copies of data items
Slide 16
 Database Recovery

Shadow Paging

 To manage access of data items by concurrent transactions, two directories

(current and shadow) are used.

 The directory arrangement is illustrated below. Here a page is a data

item.

An exmple of
shadow
paging

Slide 17
 Database Recovery
Recovery in multi database system
 A multi database system is a special distributed database system where one node
may be running relational database system under UNIX, another may be running
object-oriented system under Windows and so on.

 A transaction may run in a distributed fashion at multiple nodes.

 In this execution scenario, the transaction commits only when all these multiple
nodes agree to commit individually the part of the transaction they were executing.

 This commit scheme is referred to as “two-phase commit” (2PC).

 If any one of these nodes fails or cannot commit the part of the transaction,
then the transaction is aborted.

 Each node recovers the transaction under its own recovery protocol. Slide 18
Recovery in multi database system(cont…)
 To maintain the atomicity of multidatabase transaction(MDT) , it is
necessary to have a two level recovery mechanism.
 A global recovery manager or coordinator is needed to maintain
information needed for recovery
 The coordinator usually follows a Two-phase commit protocol which
can be explained as follows:
 Phase1: when all participating databases signal the coordinator that the
part of the MDT involving each has concluded, the coordinator sends a
“prepare for commit” message to each participant to get ready for
committing the transaction
 Each participating DB receiving that message will force write log

records to disk and send “ready to commit” or “OK” signal to the

coordinator . If the coordinator does not receive reply from a DB
within certain time out interval, it assumes a “not ok” response
Slide 19
Recovery in multi database system(cont…)

 Phase 2:If all participating databases reply ok, the transaction is successful and
the coordinator sends a commit signal to the participating DBs

 Because all the local effects of the transaction and information needed for
local recovery is recorded in the logs of participating DBs, recovery from
failure is now possible.

 Each participating DB completes transaction commit by writing a [commit]

for the transaction in the log

 If one or more of the participating DB or the coordinator have a “not OK”

response, the T has failed and the coordinator sends a message to rollback
or Undo the local effect of the transaction to each participating DB
Slide 20
Exercise

 Consider the log records shown on the next slide by transactions T1, T2, T3
and T4 with initial values of B=15, C=50, D=40 and E=25. Using deferred
update, show the final values of B, C, D and E after recovery from failure if
the crash occurred after the indicated point

B C D E
15 50 40 25

Slide 21
Continued … Initial values
B C D E
[Start_transaction,T1] 15 50 40 25
[write_item,T1,B,12]
[write_item,T1,D,10]
[commit T1]
[checkpoint]
Final values after recovery
[Start_transaction,T3]
[write_item,T3,E,30] B C D E
[commit T3] ? ? ? ?
[Start_transaction,T4]
[write_item,T4,B,18]
[commit T4]
[Start_transaction,T2]
[write_item,T2,C,28]
Crash Slide 22
Thank you!

Slide 23