Database Recovery Techniques
Outline
Databases Recovery
1. Purpose of Database Recovery
2. Types of Failure
3 . Transaction Log
4 . Data Updates
5. Data Caching
6 . Transaction Roll-back (Undo) and Roll-Forward
7 . Checkpointing
8 . Recovery schemes
9 . ARIES Recovery Scheme
10. Recovery in Multidatabase System
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.
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.
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. 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
Database Recovery
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.
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 Modified/Dirty
and Pin-Unpin bits.
• Pin-Unpin: Instructs the operating system not to
flush the data item.
• Modified: Indicates the AFIM of the data item.
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. These operations are
recorded in the log as they happen.
Database Recovery
Database Recovery
Database Recovery
Roll-back: One execution of T1, T2 and T3 as
recorded in the log.
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.
Database Recovery
7 Checkpointing
– Time to time (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.
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.
2. No-Steal: Cache cannot be flushed before transaction
commit.
3. Force: Cache is immediately flushed (forced) to disk.
4. No-Force: Cache is deferred until transaction commits
– 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 (Undo/No-redo)
Database Recovery
8 Recovery Scheme
• 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.
– 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.
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.
– It is possible that a transaction might have
completed execution and ready to commit but this
transaction is also undone.
Database Recovery
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.
X Y
X' Y'
Database
X and Y: Shadow copies of data items
X' and Y': Current copies of data items
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.
Database Recovery
The ARIES Recovery Algorithm
• The ARIES Recovery Algorithm is based on:
– WAL (Write Ahead Logging)
– Repeating history during redo:
• ARIES will retrace all actions of the database system
prior to the crash to reconstruct the database state
when the crash occurred.
– Logging changes during undo:
• It will prevent ARIES from repeating the completed
undo operations if a failure occurs during recovery,
which causes a restart of the recovery process.
Database Recovery
The ARIES Recovery Algorithm (contd.)
• The ARIES recovery algorithm consists of three
steps:
1. Analysis: step identifies the dirty (updated) pages in
the buffer and the set of transactions active at the
time of crash. The appropriate point in the log
where redo is to start is also determined.
2. Redo: necessary redo operations are applied.
3. Undo: log is scanned backwards and the operations
of transactions active at the time of crash are
undone in reverse order.
Database Recovery
10 Recovery in multidatabase system
• A multidatabase 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.
