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 consistency and durability property of
transactions.
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.

2
Cont…
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.

3
 Cont…
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.
 Sample log entry
T ID Back P Next P Operation Data item BFIM AFIM T ID Back P Next P Operation Data item BFIM AFIM
T1 0 1 Begin T1 0 1 Begin
T1 1 4 Write X X = 100 X = 200 T1 1 4 Write X X = 100 X = 200
T2 0 8 Begin T2 0 8 Begin
T1 2 5 W Y Y = 50 Y = 100 T1 2 5 W Y Y = 50 Y = 100
T1 4 7 R M M = 200 M = 200 T1 4 7 R M M = 200 M = 200
T3 0 9 R N N = 400 N = 400 T3 0 9 R N N = 400 N = 400
T1 5 nil End T1 5 nil End

4
 Cont…

4 Data Update
◦ Immediate Update: As soon as a data item is modified in
cache, the disk copy is updated.
◦ Deferred 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.
 Cont…
5. Caching of disk blocks
The flushing is controlled by dirty and Pin-
Unpin bits associated with each buffer in the
cache
The dirty bits are used to indicate whether or not
the buffer has been modified (1=modified, 0=not
modified)
As soon as the buffer is modified, the dirty bits for
the corresponding cache directory entry are set to 1
When the buffer contents are replaced from cache,
the contents must first be written back to the
corresponding disk page (only if its dirty bit is 1)
A page in the cache is pinned (bit value 1) if it can
not be written back to disk

6
 Cont…
• Two main strategies can be employed when
flushing a modified buffer back to disk
• In-place update:
• Writes the buffer back to the same original disk location
• The disk version (old value) of any changed data item is
overwritten by the cache version (new value).
• Shadow update: The modified version of a data
item does not overwrite its disk copy but is written
at a separate disk location.

7
Cont…
Write-Ahead Logging
•When in-place update 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.

8
Steal/No-Steal and Force/No-Force
Standard DBMS recovery includes the above terminologies for
specifying when a page from the DB can be written to disk from the
cache
◦ Possible ways for flushing database cache to database disk:
1.Steal: Cache can be flushed before transaction commits.
When a DBMS buffer manager needs a buffer frame for another
transaction
2.No-Steal: Cache cannot be flushed before transaction commit.
3.Force: Cache is immediately flushed (forced) to disk when the
transaction commits .
4.No-Force: Cache is deferred until transaction commits
◦ These give rise to four different ways for handling recovery:
 Steal/No-Force
 Steal/Force
 No-Steal/No-Force
 No-Steal/Force

9
Database Recovery (cont…)
6. Checkpointing
Another type of entry in the log is a checkpoint
A check point record is written into the log periodically at the point
when the system flush all DBMS buffers that haven been modified
Used to minimize the task of recovery
The recovery manager of a DBMS must decide at what interval to
take a checkpoint
The following steps defines a checkpoint operation:

1. Suspend execution of transactions temporarily.

2. Enforce writing of 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.

10
 Cont…

6 Transaction Roll-back (Undo)

 When a transaction fails for what ever reason
after updating the database, it may be
necessary to rollback the transaction
 If any data item values have been changed by
the transaction and written to the database,
they must be restored to their previous values
 The undo type log entries are used to restore
the old values of data items that must be
rolled back

11
 Database Recovery (cont…)

Roll-back
We can see the process of roll-back with the help of the
following three transactions T1, and T2 and T3.

T1 T2 T3
read_item (A) read_item (B) read_item (C)
read_item (D) write_item (B) write_item (B)
write_item (D) read_item (D) read_item (A)
write_item (A) write_item (A)

12
Database Recovery (cont…)
Roll-back: Execution of T1, T2 and T3 as recorded in the log.
A B C D
30 15 40 20
[start_transaction, T3]
[read_item, T3, C]
* [write_item, T3, B, 15, 12] 12
[start_transaction,T2]
[read_item, T2, B]
**[write_item, T2, B, 12, 18] 18
[start_transaction,T1]
[read_item, T1, A]
[read_item, T1, D]
[write_item, T1, D, 20, 25] 25
[read_item, T2, D]
** [write_item, T2, D, 25, 26]
26
[read_item, T3, A]
---- system crash ----
* T3 is rolled back because it did not reach its commit point.
** T2 is rolled back because it reads the value of item B written by
T3. 13
 Database Recovery (cont…)
8 Recovery Scheme
Deferred Update (No Undo/Redo)
• We can state a typical deferred update protocol
as follows:
• A transaction can not change the database on
disk until it reaches its commit point
• A transaction does not reach its commit point
until all of its update operations are recorded
into the log and the log is written to disk

14
 Database Recovery (cont…)

Recovery using Deferred Update

•The data update goes as follows:
1. A set of transactions record their updates in the
log.
2. 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.

15
 Database Recovery (cont…)

•Multiuser environment requires some concurrency control

mechanism to guarantee isolation property of transactions.
•In a system recovery, transactions which were recorded in
the log after the last checkpoint were redone.
•The recovery manager may scan some of the transactions
recorded before the checkpoint to get the AFIMs.
T1
T2
T3
T4
T5
t1 Time t2
checkpoint system crash

Recovery in a concurrent users environment.

16
Recovery using deferred Update
(a) T1 T2 T3 T4
read_item (A) read_item (B) read_item (A) read_item (B)
read_item (D) write_item (B) write_item (A) write_item (B)
write_item (D) read_item (D) read_item (C) read_item (A)
write_item (D) write_item (C) write_item (A)

(b) [start_transaction, T1]

[write_item, T1, D, 20]
[commit, T1]
[checkpoint]
[start_transaction, T4]
[write_item, T4, B, 15]
[write_item, T4, A, 20]
[commit, T4]
[start_transaction T2]
[write_item, T2, B, 12]
[start_transaction, T3]
[write_item, T3, A, 30]
[write_item, T2, D, 25]  system crash
• T2 and T3 are ignored because they did not reach their commit points
• T4 is redone because its commit point is after the last checkpoint.

17
 Database Recovery (cont…)

Recovery Techniques Based on Immediate

Update
Undo/No-redo Algorithm
•In this algorithm, AFIMs of a transaction are flushed to the
database disk before it commits.
•For this reason, the recovery manager undoes all
transactions during recovery.
•No transaction is redone.

18
 Database Recovery (cont…)
Recovery Techniques Based on Immediate Update
Undo/Redo Algorithm
•Recovery schemes of this category apply undo and also redo for recovery.
•In a single-user environment no concurrency control is required
•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.
•Commit table records transactions to be committed and active
table records active transactions. To minimize the work of the
recovery manager checkpointing is used
•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.

19
 Database Recovery (cont…)
Shadow Paging
•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.
•This recovery scheme does not require the use of a log in a
single user environment
•Multiuser environment may need the log for concurrency
control X Y
X' Y'

Database

X and Y: Shadow copies of data items (old)

X` and Y`: Current copies of data items (new)

20
 Database Recovery (cont…)

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.
•Example :
Current Directory Shadow Directory
(after updating pages 2, 5) (not updated)
Page 5 (old)
1 Page 1 1
2 Page 4 2
3 Page 2 (old) 3
4 Page 3 4
5 Page 6 5
6 Page 2 (new) 6
Page 5 (new)

21