Database Recovery Techniques

Introduction
• Recovery algorithms
• Recovery concepts
• Write-ahead logging
• In-place versus shadow updates
• Rollback
• Deferred update
• Immediate update
• Certain recovery techniques best used with specific concurrency
control methods

Slide 22- 2
Recovery Concepts
• Recovery process restores database to most recent consistent state
before time of failure
• Information kept in system log
• Typical recovery strategies
• Restore backed-up copy of database
• Best in cases of extensive damage
• Identify any changes that may cause inconsistency
• Best in cases of noncatastrophic failure
• Some operations may require redo

Slide 22- 3
Recovery Concepts (cont’d.)
• Deferred update techniques
• Do not physically update the database until after transaction commits
• Undo is not needed; redo may be needed
• 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

Slide 22- 4
Recovery Concepts (cont’d.)
• Undo and redo operations required to be idempotent
• Executing operations multiple times equivalent to executing just once
• Entire recovery process should be idempotent
• Caching (buffering) of disk blocks
• DBMS cache: a collection of in-memory buffers
• Cache directory keeps track of which database items are in the buffers

Slide 22- 5
Recovery Concepts (cont’d.)
• Cache buffers replaced (flushed) to make space for new
items
• Dirty bit associated with each buffer in the cache
• Indicates whether the buffer has been modified
• Contents written back to disk before flush if dirty bit equals
one
• Pin-unpin bit
• Page is pinned if it cannot be written back to disk yet

Slide 22- 6
 Recovery Concepts (cont’d.)
• Main strategies
• In-place updating
• Writes the buffer to the same original disk location
• Overwrites old values of any changed data items
• Shadowing
• 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 (BFIM)
• After-image: new value of data item (AFIM)
Slide 22- 7
 Recovery Concepts (cont’d.)
• Write-ahead logging
• Ensure the before-image (BFIM) is recorded
• Appropriate log entry flushed to disk
• Necessary for UNDO operation if needed
• UNDO-type log entries
• REDO-type log entries
In this case, the recovery mechanism must ensure that the BFIM of the data
item is recorded in the appropriate log entry and that the log entry is flushed
to disk before the BFIM is overwritten with the AFIM in the database on disk.
This process is generally known as write-ahead logging, and is necessary to
be able to UNDO the operation if this is required during recovery.
Slide 22- 8
• A REDO-type log entry includes the new value (AFIM) of the item
written by the operation since this is needed to redo the effect of the
operation from the log (by setting the item value in the database on
disk to its AFIM).
• The UNDO-type log entries include the old value (BFIM) of the item
since this is needed to undo the effect of the operation from the log
(by setting the item value in the database back to its BFIM).
• In an UNDO/REDO algorithm, both types of log entries are combined.
Additionally, when cascading rollback is possible, read_item entries in
the log are considered to be UNDO-type entries

Slide 21- 9
Recovery Concepts (cont’d.)
• Steal/no-steal and force/no-force
• Specify rules that govern when a page from the database cache can be
written to disk
• No-steal approach
• Cache buffer page updated by a transaction cannot be written to disk
before the transaction commits
• Steal approach
• Recovery protocol allows writing an updated buffer before the transaction
commits

Slide 22- 10
Recovery Concepts (cont’d.)
• Force approach
• All pages updated by a transaction are immediately written to disk
before the transaction commits
• Otherwise, no-force
• Typical database systems employ a steal/no-force strategy
• Avoids need for very large buffer space
• Reduces disk I/O operations for heavily updated pages

Slide 22- 11
1. If a cache buffer page updated by a transaction cannot be written to disk before the
transaction commits, the recovery method is called a no-steal approach. The pin-unpin
bit will be used to indicate if a page cannot be written back to disk. On the other hand, if
the recovery protocol allows writing an updated buffer before the transaction commits,
it is called steal.
Steal is used when the DBMS cache (buffer) manager needs a buffer frame for another
transaction and the buffer manager replaces an existing page that had been updated but
whose transaction has not committed. The no-steal rule means that UNDO will never be
needed during recovery, since a committed transaction will not have any of its updates
on disk before it commits.
2. If all pages updated by a transaction are immediately written to disk before the
transaction commits, it is called a force approach. Otherwise, it is called no-force. The
force rule means that REDO will never be needed during recovery, since any committed
transaction will have all its updates on disk before it is committed.
Slide 21- 12
Recovery Concepts (cont’d.)
• Write-ahead logging protocol for recovery algorithm requiring
both UNDO and REDO
• BFIM of an item cannot be overwritten by its after image
until all UNDO-type log entries have been force-written to
disk
• Commit operation of a transaction cannot be completed
until all REDO-type and UNDO-type log records for that
transaction have been force-written to disk

Slide 22- 13
Checkpoints in the System Log and Fuzzy
Checkpointing
• Taking a checkpoint
• Suspend execution of all transactions temporarily
• Force-write all main memory buffers that have been modified to disk
• Write a checkpoint record to the log, and force-write the log to the
disk
• Resume executing transactions
• DBMS recovery manager decides on checkpoint interval

Slide 22- 14
 Check point
• Keeping and maintaining logs in real time and in real environment may fill
out all the memory space available in the system.
• As time passes, the log file may grow too big to be handled at all.
Checkpoint is a mechanism where all the previous logs are removed from
the system and stored permanently in a storage disk.
• Checkpoint declares a point before which the DBMS was in consistent
state, and all the transactions were committed.

Slide 21- 15
When a system with concurrent transactions crashes and recovers, it
behaves in the following manner

Slide 21- 16
• The recovery system reads the logs backwards from the end to the last
checkpoint.
• It maintains two lists, an undo-list and a redo-list.
• If the recovery system sees a log with <Tn, Start> and <Tn, Commit> or just
<Tn, Commit>, it puts the transaction in the redo-list.
• If the recovery system sees a log with <Tn, Start> but no commit or abort
log found, it puts the transaction in undo-list.
All the transactions in the undo-list are then undone and their logs are
removed. All the transactions in the redo-list and their previous logs are
removed and then redone before saving their logs.
Slide 21- 17
Checkpoints in the System Log and
Fuzzy Checkpointing (cont’d.)
Fuzzy checkpointing
• The time needed to force-write all modified memory buffers may
delay transaction processing because of Suspend execution of
transactions temporarily.
• To reduce this delay, it is common to use a technique called fuzzy
checkpointing.
• System can resume transaction processing after a begin_checkpoint record is
written to the log
• Previous checkpoint record maintained until end_checkpoint record is written

Slide 22- 18
 Transaction Rollback
• Transaction failure after update but before commit
• Necessary to roll back the transaction
• Old data values restored using undo-type log entries
If any data item values have been changed by the transaction and written
to the database, they must be restored to their previous values (BFIMs). The
undo-type log entries are used to restore the old values of data items that
must be rolled back.
• 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
Slide 22- 19
• If a transaction T is rolled back, any transaction S that has, in the
interim, read the value of some data item X written by T must also be
rolled back.
• Similarly, once S is rolled back, any transaction R that has read the
value of some data item Y written by S must also be rolled back; and
so on. This phenomenon is called cascading rollback,
• and can occur when the recovery protocol ensures recoverable
schedules but does not ensure strict or cascadeless schedules

Slide 21- 20
Figure 22.1 Illustrating
cascading rollback (a
process that never occurs
in strict or cascadeless
schedules) (a) The read
and write operations of
three transactions (b)
System log at point of
crash (c) Operations
before the crash

Slide 22- 21
NO-UNDO/REDO 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 (no undo)
• Can only be used for short transactions and transactions that change few
items
• Buffer space an issue with longer transactions

Slide 22- 22
 NO-UNDO/REDO Recovery Based
on Deferred Update (cont’d.)

• 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

Slide 22- 23
NO-UNDO/REDO Recovery Based on
Deferred Update (cont’d.)

Figure . An example of a recovery timeline to illustrate the effect of checkpointing

Slide 22-24
Recovery Techniques Based on
Immediate Update
• 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)

Slide 22- 25
Figure 22.3 An example
of recovery using
deferred update with
concurrent transactions
(a) The READ and
WRITE operations of
four transactions (b)
System log at the point
of crash

Slide 22- 26
Shadow Paging

• No log required in a single-user environment

• Log may be needed in a multiuser environment for the concurrency control
method
• 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

Slide 22- 27
Shadow Paging (cont’d.)
• 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
• NO-UNDO/NO-REDO technique

Slide 22- 28
Shadow Paging (cont’d.)

Figure. An example of shadow paging

Slide 22- 29
• One disadvantage of shadow paging is that the updated database pages
change location on disk. This makes it difficult to keep related database pages
close together on disk without complex storage management strategies.
• Furthermore, if the directory is large, the overhead of writing shadow
directories to disk as transactions commit is significant. A further
complication is how to handle garbage collection when a transaction
commits.
• The old pages referenced by the shadow directory that have been updated
must be released and added to a list of free pages for future use. These
pages are no longer needed after the transaction commits.Another issue is
that the operation to migrate between current and shadow directories must
be implemented as an atomic operation.
Slide 21- 30
Database Backup and Recovery
from Catastrophic Failures
• Database backup
• Entire database and log periodically copied onto inexpensive storage medium
• Latest backup copy can be reloaded from disk in case of catastrophic failure
• Backups often moved to physically separate locations
• Subterranean storage vaults

Slide 22- 31
Database Backup and Recovery
from Catastrophic Failures (cont’d.)
• Backup system log at more frequent intervals and copy to magnetic
tape
• System log smaller than database
• Can be backed up more frequently
• Benefit: users do not lose all transactions since last database backup

Slide 22- 32
Re-do and Undo concept
System crash happen then database recovery reads to the log and find
out all transaction
commit entry
(commit, T)
-not found nothing to be done
- found (write to be applied)
writes are needed to be done this operation known redo operation.

Slide 21- 33
(Commit, T)
(write, t, x, 14)
(write, t, y, 15)
Redo must be followed is called idempotent (doing at once)
Immediate database modification
allow uncommitted writes
old, new
log is written before actual write operation

Slide 21- 34
• transacation crash
• find the log
search all the record (commit, T) search
-if not found
(commit, T) missing, =>undo
if found
(commit, T) re-done/redo

Slide 21- 35
(Start, t)
--------
data written before commit
--------
(commit, T)

**undo -> reverse order of log records

** redoing -> forward order of log record
undone then redone
Slide 21- 36