CE 301T

CHAPTER 22
Database Recovery Techniques

Dr. Najma Ismat

nismat@ssuet.edu.pk

Computer Engineering Depar

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 2

22.1 Recovery Concepts
◼ Recovery process restores the database to a most recent
consistent state before time of failure
◼ Information kept in the system log
◼ Typical recovery strategies
◼ Restore a backed-up copy of the 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
◼ Deferred update techniques
◼ Do not physically update the database until after the
transaction commits
◼ Undo is not needed; redo may be needed
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 3
22.1 Recovery Concepts
◼ Two main policies for recovery from noncatastrophic
transaction failures
1. Deferred update techniques
◼ Do not physically update the database until after the transaction
commits, then the updates are recorded in the database
◼ Before reaching commit, all transaction updates are recorded in
the local transaction workspace or the main memory buffers
◼ Undo is not needed
◼ If a transaction fails before reaching its commit point, it will not
have changed the database on disk in any way
◼ redo may be needed
◼ effect of the operations of a committed transaction from the log,
because their effect may not yet have been recorded in the
database on disk.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 4
Recovery Concepts (cont’d.)
2. Immediate update techniques
◼ Database may be updated by some operations of a transaction
before it reaches the commit point
◼ Operations also recorded in the log
◼ Recovery still possible
◼ Undo and redo operations required to be idempotent
◼ If a transaction fails after recording some changes in the database on
disk but before reaching its commit point, the effect of its operations
on the database must be undone and must be rolled back.
◼ Executing operations multiple times is equivalent to executing just
once
◼ The entire recovery process should be idempotent

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 5

Recovery Concepts (cont’d.)
◼ 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 (similar to page tables)
◼ 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 6

 Recovery Concepts (cont’d.)
◼ Two main strategies can be employed when flushing a
modified buffer back to disk.
1. In-place updating
◼ Writes the buffer to the same original disk location
◼ Overwrites old values of any changed data items, so the single
copy of disk each database disk block is maintained
2. 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)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 7

Recovery Concepts (cont’d.)
◼ When in-place updating is used, it is necessary to use a log
for recovery
◼ Write-ahead logging
◼ Ensure the before-image (BFIM) is recorded
◼ Appropriate log entry flushed to disk before the BFIM is overwritten
with the AFIM in the database on disk
◼ Necessary for UNDO operation if needed
◼ UNDO-type log entries
◼ includes the new value (AFIM) of the item written by the operation,
this is needed to redo the effect of the operation from the log
◼ REDO-type log entries
◼ the old value (BFIM) of the item since this is needed to undo the
effect of the operation from the log
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 8
 Recovery Concepts (cont’d.)
◼ The rules that govern when a page from the database cache can be
written to disk:
1. No-steal approach
◼ 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 set to 1 (pin) to indicate that a cache buffer cannot be
written back to disk (UNDO will never be needed)
2. Steal approach
◼ If the recovery protocol allows for writing an updated buffer before the
transaction commits
◼ It 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 been committed.
◼ UNDO will never be needed during recovery

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 9

 Recovery Concepts (cont’d.)
◼ Force approach
◼ If all pages updated by a transaction are immediately written to disk before the
transaction commits
◼ Otherwise, 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.
◼ Typical database systems employ a steal/no-force strategy
◼ Avoids the need for a very large buffer space
◼ Reduces disk I/O operations for heavily updated pages
• 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.
• The advantage of steal is that it avoids the need for a very large buffer space to store all
updated pages in memory
• The advantage of no-force is that an updated page of a committed transaction may still be
in the buffer when another transaction needs to update it, thus eliminating the I/O cost to
write that page multiple times to disk and possibly having to read it again from disk.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 10
 Recovery Concepts (cont’d.)
◼ To permit recovery when in-place updating is used, the appropriate
entries required for recovery must be permanently recorded in the log on
disk before changes are applied to the database.
◼ 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 11

Checkpoints in the System Log and
Fuzzy Checkpointing
◼ Entry in the log is called a checkpoint, which contains the list of active
transactions
◼ Checkpoint is a record written into the log periodically at that point when the
system writes out to the database on disk all DBMS buffers that have been
modified.
◼ The recovery manager of a DBMS must decide at what intervals to take a

checkpoint.
◼ The interval may be measured in time—say, every m minutes—or in the

number t of committed transactions since the last checkpoint, where the

values of m or t are system parameters.
◼ Taking a checkpoint
1. Suspend execution of all transactions temporarily
2. Force-write all main memory buffers that have been modified to disk
3. Write a checkpoint record to the log, and force-write the log to the disk
4. Resume executing transactions
5. DBMS recovery manager decides on checkpoint interval
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 12
 Checkpoints in the System Log and
Fuzzy Checkpointing (cont’d.)
◼ The time needed to force-write all modified memory buffers may delay
transaction processing because of step 1, which is not acceptable in
practice.
◼ To overcome this the solution is:
◼ 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
◼ Until step 2 is completed, the previous checkpoint record should remain

valid.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 13

Transaction Rollback
◼ Transaction failure after update but before commit
◼ Necessary to roll back the transaction

◼ Old data values restored using undo-type log entries

◼ 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 14

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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 22- 15