St.

Mary’s University
Department of Computer Science

Chapter 5: Database Recovery

Techniques
Prepared By Bekretsyon B. (M.Sc.)

1 1
Database Recovery
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).

 Database recovery techniques are methods and processes used to restore and recover
data in the event of a database failure or corruption.
 The purpose of data recovery in a database is to restore and recover data that has been
lost or corrupted due to a variety of issues, such as hardware failure, software bugs, or
human error.
Types of Failure
 The database may become unavailable for use due to:
 Transaction failure: occur when a transaction in the database fails to complete due
to an error or interruption.
 System failure: System failures refer to hardware or software failures that cause the
database to become unavailable or inaccessible.
 Media failure: Media failures refer to failures in the storage media used by the
database, such as disk failures, tape failures, or corruption of data on the storage
media.

2
Cont’d
Transaction Log
 Transaction logs: record all changes made to the database, including insertions, updates, and
deletions, as well as transactions that have not yet been committed.
 Transaction log is used to recover the database to a consistent state in the event of a failure.
 Rollback recovery: involves undoing a transaction that was not committed at the time of the
failure.
 The transaction log is used to identify the uncommitted transaction and undo the changes
made by that transaction.
 "before image" and "after image" refer to the state of a database record before and after a
transaction is executed.
 A "before image" is a copy of a database record before it is updated or deleted by a transaction. It
represents the state of the record at the beginning of the transaction.
 An "after image" is a copy of a database record after it is updated or inserted by a transaction. It
represents the state of the record at the end of the transaction.

3
 Cont’d
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.

Next P Operation Data item BFIM AFIM

1 Begin
4 Write X X = 100 X = 200
8 Begin
5 W Y Y = 50 Y = 100
7 R M M = 200 M = 200
9 R N N = 400 N = 400
nil End

4
Cont’d
Data Update
 "In-place data" refers to a technique in which data is modified directly in the location where it is
stored, without the need for a copy of the data to be made.
 "Immediate update" refers to a technique in which changes made to the data in a database are
immediately reflected in the database itself, rather than being cached or buffered for a later update.
 "Deferred update" refers to a technique in which changes made to the data in a database are not
immediately reflected in the database itself, but are instead buffered or cached for a later update.
 "Shadow update" refers to a technique in which changes made to the data in a database are first
applied to a copy of the data, known as a "shadow copy", before being applied to the original data.
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 dirty and Pin-Unpin bits.
 Dirty bits=1: Indicates that the data item is modified. 0, when a page is first read from the
database disk into a cache buffer. Data are flushed (written) to the disk only if its dirty bit is 1.
 Pin-Unpin bits: a page in cache is pinned (bit value=1)

5
Cont’d
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.
Write-Ahead Logging
 When in-place update (immediate or deferred) is used then log is necessary for recovery .
 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.

6
COnt’d
Check pointing
 A [checkpoint] record is 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.
 As a consequence of this, all transactions that have their [commit, T] entries in the log before a
[checkpoint] entry do not need to have their WRITE operations redone in case of a system crash,
since all their updates will be recorded in the database on disk during checkpointing.
 Advantages of using Checkpoints :
 It speeds up data recovery process.

 Checkpoint records in log file is used to prevent unnecessary redo operations.

 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.
7
Cont’d
Recovery Scheme
 Deferred Update (No Undo/Redo)
 The data update goes as follows:
 A set of transactions record their updates in the log.
 At commit point under WAL scheme, these updates are saved on database disk.
 Before reaching commit, all transaction updates are recorded in the local transaction
workspace (or buffers).

8
Recovery Techniques Based on Deferred Update
 During commit, the updates are first recorded persistently in the log and then written to the database.
 If a transaction fails before reaching its commit point, it will not have changed the database in any way,
so UNDO is not needed.
 It may be necessary to REDO the effect of the operations of a committed transaction from the log,
because their effect may not yet have been recorded in the database. Hence, deferred update is also
known as the NO-UNDO/REDO algorithm.

9
Cont’d
Deferred Update with concurrent users
 This environment requires some concurrency control mechanism to guarantee isolation property of
transactions.
 In the system recovery, transactions which were recorded in log after last checkpoint were redone.

10
Cont’d
Deferred Update with concurrent users
 Two tables are required for implementing this protocol:
 Active table: All active transactions are entered in this table.
 Commit table: Transactions that have been 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.
Recovery Techniques Based on Immediate Update
 Undo/redo Algorithm
 In this algorithm AFIMs of a transaction are flushed to the database disk under WAL
before it commits.
 However, these operations are typically recorded in the log on disk by force writing
before they are applied to the database, making recovery still possible.
 For this reason the recovery manager undo all transactions during recovery.

11
Cont’d
 If a transaction fails after recording some changes in the database but before reaching its commit
point, the effect of its operations on the database must be undone; that is, the transaction must
be rolled back.
 In the general case of immediate update, both undo and redo may be required during recovery.
 This technique, known as the UNDO/REDO algorithm, requires both operations.
Recovery Techniques Based on Immediate Update
 Undo/Redo Algorithm (Single-user environment)
 Note that at any time there will be one transaction in the system and it will be either in the
commit table or in the active table.
 The recovery manager performs:
 Undo of a transaction if it is in the active table.
 Redo of a transaction if it is in the commit table.

12
UNDO/REDO Recovery Based on Immediate Update with
Concurrent Execution
 Use two lists of transactions maintained by the system: the committed transactions since the last
checkpoint and the active transactions.

 Undo all the write_item operations of the active (uncommitted) transactions, using the UNDO
procedure.

 Redo all the write_item operations of the committed transactions from the log, in the order in
which they were written into the log.
X Y
X' Y'
Shadow Paging
 Does not require the use of a log in a single user environment. Database
 In a multiuser environment, a log may be needed for the X and Y: Shadow copies of data items
concurrency control method.. X' and Y': Current copies of data
 AFIM and BFIM are stored in two different places on the disk. items

13
Cont’d
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.

An example of shadow paging

14
Cont’d
Shadow Paging…
 To recover from a failure during transaction execution, it is sufficient to free the modified database
pages and to discard the current directory.
 The state of the database before transaction execution is available through the shadow directory,
and that state is recovered by reinstating the shadow directory.
 Committing a transaction corresponds to discarding the previous shadow directory.
Recovery in multi database system
 Here, transaction commits only when all these multiple nodes agree to commit individually the part
of the transaction they were executing.
 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.

15
Cont’d
 A global recovery manager or coordinator is needed to maintain information needed for recovery
 The coordinator usually follows a Two-phase commit protocol :
 Phase1: the coordinator sends a “prepare for commit” message to each participant to get ready for
committing the transaction
 Each participating DB receiving that message will force write log records to disk and send “ready to
commit” or “OK” signal to the coordinator .
 If the coordinator does not receive reply from a DB within certain time out interval, it assumes a
“not ok” response
 Phase 2:If all participating databases reply ok, the transaction is successful and the coordinator sends a
commit signal to the participating DBs
 Each participating DB completes transaction commit by writing a [commit] for the transaction in
the log
 If one or more of the participating DB or the coordinator have a “not OK” response, the T has
failed and the coordinator sends a message to rollback or Undo the local effect of the transaction
to each participating DB.
16
Exercise

 Consider the log records shown on the next slide by transactions T1, T2, T3 and T4 with initial
values of B=15, C=50, D=40 and E=25. Using deferred update, show the final values of B, C, D
and E after recovery from failure if the crash occurred after the indicated point.

17