Database Recovery Techniques
Acknowledgement:
Most of these slides have been adapted from
slides made available by Pearson/Addison Wesley
to accompany Elmasri and Navathe’s textbook
Fundamentals of Database Systems
Outline



Introduction
Fundamental techniques
Recovery Approaches



Shadow Paging
Deferred Update
Immediate Update
2
Introduction

Purpose of database recovery



To bring the database into the most recent
consistent state that existed prior to a failure
Preserve Atomicity and Durability ACID properties
Types of failure

System failure


Addressing error, application error, operating system
fault, etc.
Media failure

RAM failure, disk head crash, power disruption, etc.
3
Transaction Rollback

Transaction failure after update but before
commit



Necessary to roll back the transaction
Old data values must be restored
Cascading rollback


If transaction T is rolled back, any transaction S
that has read value of item written by T must also
be rolled back
Almost all recovery mechanisms designed to avoid
this
4
Notice: Actions out of the Database
may not be Rolled Back


Example actions: generating and printing
messages and reports
If transaction fails before completion, may not
want user to get these reports


Reports should be generated only after transaction
reaches commit point
Commands that generate reports issued as batch
jobs executed only after transaction reaches
commit point

Batch jobs canceled if transaction fails
5
Writing Strategies

In-place updating



Shadowing




Writes the buffer to the same original disk location
Overwrites old values of any changed data items
Writes an updated buffer at a different disk location,
to maintain multiple versions of data items
Not typically used in practice
Before-image: old value of data item
After-image: new value of data item
6
Writing Rules


Specify rules that govern when a page from the
database cache can be written to disk
Steal vs. No-steal

Steal approach (may require UNDO)


Recovery protocol allows writing an updated buffer
before the transaction commits
No-steal approach (UNDO not needed)

Cache buffer page updated by a transaction cannot
be written to disk before the transaction commits
7
Writing Rules (2)

Force vs. No-force

Force approach (REDO not needed)



All pages updated by a transaction are immediately
written to disk before the transaction commits
Otherwise, no-force (may require REDO)
Typical database systems employ a steal/no-force
strategy (UNDO/REDO approaches)


Avoids need for very large buffer space
Reduces disk I/O operations for heavily updated
pages
8
Recovery Approaches



Shadow paging (NO-UNDO/NO-REDO)
Deferred update (NO-UNDO/REDO)
Immediate update


UNDO/REDO
UNDO/NO-REDO
9
Recovery Based on Shadow Paging

Shadow paging considers disk to be made of n
fixed-size disk pages



Directory with n entries is constructed
When transaction begins executing, directory
copied into shadow directory to save while current
directory is being used
Shadow directory is never modified
10
The NO-UNDO/NO-REDO Shadow
Paging Algorithm

New copy of the modified page created and
stored elsewhere



Current directory modified to point to new disk
block
Shadow directory still points to old disk block
Failure recovery


Discard current directory
Free modified database pages
11
Deferred and Immediate Update
Recovery Techniques

Deferred update techniques



Do not physically update the database until after
transaction commits
Undo is not needed; redo may be needed, relying
on the transaction log
Immediate update techniques



Database may be updated by some operations of a
transaction before it reaches commit point
Operations also recorded in log
Recovery still possible
12
System Log

Append-only file



Stored on disk




Keep track of all operations of all transactions
In the order in which operations occurred
Persistent except for disk or catastrophic failure
Periodically backed up
Guard against disk and catastrophic failures
Main memory buffer


Holds records being appended
Occasionally whole buffer appended to end of log on disk
(flush)
13
System Log Entries

[start_transaction, T]


[write_item, T, X, old_value, new_value]




T has changed the value of item X from old_value to new_value.
Before Image (old_value) needed to undo(X)
After Image (new_value) needed to redo(X)
[commit, T]



Transaction T has started execution.
T has completed successfully and committed
T’s effects (writes) must be durable
[abort, T]


T has been aborted
T’s effects (writes) must be ignored and undone
14
Write-Ahead Logging (WAL)


Used to ensure that the log is consistent with the database, and to
ensure that the log can be used to recover the database to a consistent
state; ensures the before-image (BFIM) is recorded
Two rules:

Log record for a page must be written before corresponding page is
flushed to disk


All log records must be written before commit


For Atomicity, so that each operation is known and can be undone if
necessary
For Durability, so that the effect of a committed transaction is known
A transaction is said to be committed (reached the commit point) when:


All of its operations are executed, and
All its log records are flushed to disk
15
Checkpointing


Employed to save redo effort
Occasionally flush data buffers
1)Suspend execution of transactions temporarily
2)Force-write modified (dirty) buffer data to disk
3)Append [checkpoint] record to log
4)Flush log to disk
5)Resume normal transaction execution

During recovery, redo required only for log
records appearing after [checkpoint] record
16
Recovery Based on Deferred Update

Deferred update concept




Postpone updates to the database on disk until the
transaction completes successfully and reaches its
commit point
Redo-type log entries are needed
Undo-type log entries not necessary
Can only be used for short transactions and
transactions that change few items

Buffer space an issue with longer transactions
17
The NO-UNDO/REDO Deferred
Update Algorithm

Deferred update protocol

Transaction cannot change the database on disk
until it reaches its commit point


All buffers changed by the transaction must be
pinned until the transaction commits (no-steal
policy)
Transaction does not reach its commit point until
all its REDO-type log entries are recorded in log
and log buffer is force-written to disk
18
Recovery Techniques Based on
Immediate Update

Immediate update concept

Database can be updated immediately




No need to wait for transaction to reach commit
point
Not a requirement that every update be immediate
UNDO-type log entries must be stored
Recovery algorithms


UNDO/NO-REDO (steal/force strategy)
UNDO/REDO (steal/no-force strategy)
19
The UNDO-REDO Immediate Update
Algorithm

After a crash:
1)UNDO transactions that had not committed


To ensure Atomicity
Partial results of uncommitted transactions should be discarded
2)REDO committed transactions




To ensure Durability
Modified blocks in memory might have not be written back to
disk
Uses a system log with write-ahead logging policy
Example: the AIRES recovery algorithm, used in many IBM
relational database products
20
The UNDO/REDO Recovery Process
1)ANALYSIS
a) Scan log from the checkpoint
b) Identify the transactions to be redone and undone
2)REDO (roll-forward)
a) Scan the log from head to tail (forwards in time)
b) Redo updates of committed transactions
c) Use after image for new values
3)UNDO (roll-back)
a) Scan log from tail to head (backward in time)
b) Restore before image by undoing updates of active transactions, writing
compensating log records for undone operations
- e.g., the compensation action for an insert is a delete
c) In case of crash during recovery, the algorithm redoes up to the last
compensation operation and starts undoing from the previous one
21
Recovery According to Different
Strategies

NO-UNDO/NOREDO

T1 to T5: do
nothing

NO-UNDO/REDO



T1: do nothing
T2, T3: REDO
T4, T5: do nothing

UNDO/REDO



T1: do nothing
T2, T3: REDO
T4, T5: UNDO

UNDO/NO-REDO



T1: do nothing
T2, T3: do nothing
T4, T5: UNDO
22