Database Recovery

Techniques

1
1
Databases Recovery
1. Recovery Concepts
I. Types of Failure
II. Transaction Log
III. Write a head Log
IV. Data Caching
V. Check pointing
VI. Transaction Roll-back (Undo) and Roll-
Forward
2. Data Update & Recovery Schema

2
2
 Transaction Manager : Accepts transaction commands from an application, which
tell the transaction manager when transactions begin and end,
as well as information about the expectations of the
application.
The transaction processor performs the following tasks:
Transaction Request
 Logging: In order to assure
durability, every change in the
database is logged separately on
Query Transaction Log
Processor Manager Manager
disk.

 Log manager initially writes the

log in buffers and negotiates with
Buffer Recovery
Manager Manager
the buffer manager to make sure
that buffers are written to disk at
appropriate times.

Data  Recovery Manager: will be able

------------ to examine the log of changes and
Log restore the database to some
consistent state.
3
 1. Recovery Concept
i. Purpose of Database Recovery
– To bring the database into the last consistent state, which
existed prior to the failure.
– To preserve transaction properties (Atomicity &and
Durability).
• The recovery manager of a DBMS is responsible to ensure
– Atomicity by undoing the action of transaction that do
not commit
– Durability by making sure that all actions of committed
transaction survive system crash
ii. Types of Failure
– The database may become unavailable for use due to :
• Transaction failure: Transactions may fail because of
incorrect input, deadlock.
• System failure: System may fail because of addressing
error, application error, operating system fault, RAM
failure, etc.
• Media failure: Disk head crash, power disruption, 4 etc. 4
 To recover from system failure , the system keeps
information about the change in the system log
 Strategy for recovery may be summarized as :
 Recovery from catastrophic
 If there is extensive damage to the wide portion of the database
 This method restore a past copy of the database from the backup
storage and reconstructs operation of a committed transaction from the
back up log up to the time of failure
 Recovery from non-catastrophic failure
 When the database is not physically damaged but has be come in
consistent
 The strategy uses undoing and redoing some operations in order
to restore to a consistent state : example

5
5
 For instance,
– If failure occurs between commit and database buffers being
flushed to secondary storage then, to ensure durability, recovery
manager has to redo (roll forward) transaction’s updates.
– If transaction had not committed at failure time, recovery
manager has to undo (rollback) any effects of that transaction for
atomicity. Example,

Fig 2 :
status of
transaction
s at the
time of
system
– DBMS starts at time t0, but fails at time tf. fails
– T1 and T6 have to be undone. In absence of any other
information, recovery manager has to redo T2, T3, T4, and T5.
6
iii. 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 (appended file) called Transaction log
– These log files becomes very useful in brining back the
system to a stable state after a system crash.
– A sample log is given below. Back P and Next P point to
the previous and next log records of the same transaction.
T ID Back P Next P Operation Data item BFIM AFIM
T1 0 1 Begin
T1 1 4 Write X X = 100 X = 200
T2 0 8 Begin
T1 2 5 W Y Y = 50 Y = 100
T1 4 7 R M M = 200 M = 200
T3 0 9 R N N = 400 N = 400
T1 5 nil End

7
7
V. Write-Ahead Logging
 When in-place update (immediate or
deferred) is used then log is necessary for
recovery
 This log 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.

9
9
  Standard Recovery Terminology
 Possible ways for flushing database cache to database disk:
i. No-Steal: Cache cannot be flushed before transaction commit. (don’t
allow buffer-pool frames with uncommited updates to overwrite
committed data on disk.)
ii. Steal: Cache can be flushed before transaction commits.
Advantage:
 it avoids the need for a very large buffer space to store all updated pages in the
memory
iii. Force: if all Cache updates are immediately flushed
(forced) to disk when a transaction commits----- force
writing
iv. No-Force: if Cached are flushed to a disk when the need
arise after a committed transaction (Write as little as
possible)
Advantage:
 an updated pages of a committed transaction may still be in the buffer when an
other transaction needs to update
 If this page is updated by multiple transaction, it eliminates the I/O cost to read that
10
page again , 10
 These give rise to four different ways for
handling recovery:
Steal/No-Force (Undo/Redo)
Steal/Force (Undo/No-redo)
No-Steal/No-Force (No-undo/Redo)
No-Steal/Force (No-undo/No-redo)
VI. Checkpointing
 Log file is used to recover failed DB but we may not know how far
back in the log to search. Thus
 Checkpoint is a Point of synchronization between database and log
file.
 Time to time (randomly or under some criteria) the database
flushes its buffer to database disk to minimize the task of recovery.
 When failure occurs, redo all transactions that committed since the
checkpoint and undo all transactions active at time of crash.
 In previous example ,Figure 2, on slide 6 , with checkpoint at time
tc, changes made by T2 and T3 have been written to secondary
storage. Thus: only redo T4 and T5, undo transactions T1 and T6.
 At what interval to take a check pointing may be measured :
 In terms of time , say m minutes after the last check point
 The # t of committed transaction since the last check point

12
12
 The following steps defines a checkpoint operation:
i. Suspend execution of transactions temporarily.
ii. Force write modified buffer data to disk.
iii. Write a [checkpoint] record to the log, save the log to disk.
iv. Resume normal transaction execution.
VII. Transaction Roll-back (Undo) and Roll-Forward (Redo)
 If transaction fails for what so ever reason after updating the
data base it must be necessary to roll back
 IF a transaction T is roll back , any transaction , S, that has
read the value of some data item X written by T must be also
be roll back (cascade less or strict schedules)
 Similarly once S is roll back, any transaction R that has read
the values of some data item Y written by S must also be roll
back, and so on..
 To maintain such cases, 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. These
operations are recorded in the log as they happen.

14
14
Example

15
15
Roll-back: One execution of T1, T2 and T3 as recorded in the
log.

Remark:
• Only write item operation need to be undone during transaction roll back
• Read item operations are recorded in the log only to determine whether
cascading roll back of additional transaction is needed
16
16
2. Data Update and Recovery Scheme : Three types
i. Deferred Update (No Undo/Redo)
– The data update goes as follows:
 A set of transactions records their updates in the log.
 At commit point under WAL scheme these updates are saved on
database disk.
 No undo is required because no AFIM is flushed to the disk before a
transaction commits.
 After reboot from a failure the log is used to redo all the transactions
affected by this failure.
– Limitation: out of buffer space may be happened because transaction
changes must be held in the cache buffer until the commit point
– Type of deferred updated recovery environment
 Single User and Multiple user environment
a) Deferred Update in a single-user system
 There is no concurrent data sharing in a single user system.
 The data update goes as follows:
 A set of transactions records their updates in the log.
 At commit point under WAL scheme these updates are saved on
database disk.
17
17
 2: Write
Update data

1
LOG File 3:
Fo
rc
e
w
ri
te
lo
g
to
D
is
k
COMMIT
4

t e
da
up
5:

Database
•Example: Differed Update for single user

19
19
 b) Deferred Update with concurrent users
 This 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.

T4 and T5 are ignored because they didn’t reach their commit points
T2 and T3 are redone because their commit point is after the last
checkpoint 20
20
 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.
 It is possible that a commit table transaction may be redone
twice but this does not create any inconsistency because of a
redone is “idempotent”,
 that is, one redone for an AFIM is equivalent to multiple
redone for the same AFIM.

21
21
ii. 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.
– It is possible that a transaction might have completed execution
and ready to commit but this transaction is also undone.

22
22
iii. Shadow Paging
 This technique does not require LOG in single user environment
 Maintain two page tables during life of a transaction: current page
and shadow page table.
 When transaction starts, two pages are the same.
 Shadow page table is never changed thereafter and is used to restore
database in event of failure.
 During transaction, current page table records all updates to
database.
 When transaction completes, current page table becomes shadow
page table.
X Y
X' Y'

Database

X and Y: Shadow copies of data items

X' and Y': Current copies of data items

23
23
 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.

24
24
END