Chapter 7

Database Recovery Techniques

1
Databases Recovery

1. Recovery Concepts
I. Types of Failure
II. Transaction Log
III. Write a head Log
IV. Data Caching
V. Checkpointing
VI. Transaction Roll-back (Undo) and Roll-Forward
2. Data Update & Recovery Schema

2
 Databases Recovery

❖ Database recovery refers to the process of restoring a database to a

consistent and usable state after a failure, error, or any unforeseen event that
may compromise the integrity or availability of the data.
❖ Purpose of Database Recovery: The primary goal of database recovery is to
ensure that the data remains consistent and can be reliably accessed and used
despite failures.
❖ To bring the database into the last consistent state, which existed prior to the
failure.
❖ To preserve transaction ACID properties
❖ The recovery manager of a DBMS is responsible to ensure atomicity by undoing the
action of transaction that do not commit. Durability by making sure that all actions of
committed transaction survive system crash. Consistency by analysing the transaction
log, the system can identify the changes made by each transaction and apply or undo
them in a way that maintains overall consistency. The recovery process takes into
account the isolation levels of transactions. This involves properly sequencing the
3
application of changes to maintain transactional isolation.
▪ Transaction Manager : A Transaction Manager (TM) is a component of a
database management system (DBMS) or transaction processing system responsible
for coordinating and managing transactions. Its primary role is to ensure the
atomicity, consistency, isolation, and durability (ACID properties) of transactions in
a database.
▪Transaction Manager : Accepts transaction commands from an application, which
tell the transaction manager when transactions begin and end,
as well as information about the expectations of the
application.

▪The transaction processor performs the following tasks:

4
 Transaction Request ✓ Logging: In order to assure
durability, every change in the
Query Transaction Log database is logged separately on
Processor Manager Manager disk.

✓ Log manager initially writes the

Buffer Recovery log in buffers and negotiates with
Manager Manager the buffer manager to make sure
that buffers are written to disk at
appropriate times.
Data
✓ Recovery Manager: will be able
------------
Log to examine the log of changes and
restore the database to some
consistent state. 5
❖ In General, these components work together in the following way during
the recovery process:
➢ Logging ensures that changes are recorded in a sequential log.
➢ Log Manager oversees the management and organization of the
transaction log.
➢ Recovery Manager uses the transaction log to analyse, redo, and
undo operations during the recovery process, bringing the database
to a consistent and durable state.
❖ This combination of logging, log management, and recovery management is
critical for maintaining data integrity and consistency in the face of failures or
crashes in a database system. It adheres to the ACID properties (Atomicity,
Consistency, Isolation, Durability) and is fundamental to the reliability of
modern database management systems.
6
1. Recovery Concept
i. Purpose of Database Recovery
– To bring the database into the last consistent state, which existed
prior to the failure.
– To preserve transaction properties (Atomicity & Durability).
• The recovery manager of a DBMS is responsible to ensure
– atomicity by undoing the action of transaction that do
not commit
– Durability by making sure that all actions of committed
transaction survive system crash
ii. Types of Failure
– The database may become unavailable for use due to :
• Transaction failure: Transactions may fail because of
incorrect input, deadlock.
• 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. 7
▪ To recover from system failure , the system keeps information about the
change in the system log
▪ Strategy for recovery may be summarized as :
▪ Recovery from catastrophic
▪ If there is extensive damage to the wide portion of the database
▪ This method restore a past copy of the database from the backup
storage and reconstructs operation of a committed transaction
from the back up log up to the time of failure
▪ Recovery from non-catastrophic failure
▪ When the database is not physically damaged but has be come
inconsistent
▪ The strategy uses undoing and redoing some operations in order
8
to restore to a consistent state : example
▪ For instance,
– If failure occurs between commit and database buffers being flushed to
secondary storage then, to ensure durability, recovery manager has to
redo (roll forward) transaction’s updates.
– If transaction had not committed at failure time, recovery manager has
to undo (rollback) any effects of that transaction for atomicity.
Example, Fig 2 :
status of
transactions
at the time of
system fails
– DBMS starts at time t0, but fails at time tf.
– T1 and T6 have to be undone. In absence of any other information,
recovery manager has to redo T2, T3, T4, and T5. 9
iii. Transaction Log: a transaction log (also known as a database log or
transaction journal) is a sequential record of all changes made to the
database.
❖ The primary purpose of a transaction log is to provide a reliable record
of database modifications that can be used for recovery in the event of
system failures or crashes.
❖ 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. Suppose there's a transaction that updates the
balance of a bank account:
❖BFIM: The original balance of the account before the update.
❖AFIM: The new balance of the account after the update.
❖ These values and other information is stored in a sequential file (appended
file) called Transaction log
❖ These log files becomes very useful in brining back the system to a stable
state after a system crash.
❖ A sample log is given below. Back P and Next P point to the previous and
10
next log records of the same transaction.
 ❖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

11
IV. 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
▪ When DBMS request for read /write operation on some item
▪ It check the requested data item is in the cache or not
▪ If it is not, the appropriate disk block are copied to the cache
▪ If the cache is already full, some buffer replacement policy can be
used . Like
▪ Least recent used (LRU)
▪ FIFO
▪ While replacing buffers , first of all the updated value on that
buffer should be saved on the appropriate block in the data base
12
V. Write-Ahead Logging
▪ When in-place update (immediate or deferred) is used then log
is necessary for recovery
▪ This log 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.
13
❑ Standard Recovery Terminology
▪ Possible ways for flushing database cache to database disk:
i. No-Steal: Cache cannot be flushed before transaction commit.
ii. Steal: Cache can be flushed before transaction commits.
Advantage:
➢ it avoids the need for a very large buffer space to store
all updated pages in the memory
iii. Force: if all Cache updates are immediately flushed (forced) to
disk when a transaction commits-----→ force writing
iv. No-Force: if Cached are flushed to a disk when the need arise
after a committed transaction
Advantage:
➢ an updated pages of a committed transaction may still be
in the buffer when an other transaction needs to update
➢ If this page is updated by multiple transaction, it
eliminates the I/O cost to read that page again ,
▪ These give rise to four different ways for handling recovery:
• Steal/No-Force (Undo/Redo)
• Steal/Force (Undo/No-redo)
• No-Steal/No-Force (No-undo/Redo)
14
• No-Steal/Force (No-undo/No-redo)
VI. Checkpointing
❖ Log file is used to recover failed DB but we may not know how far
back in the log to search. Thus
❖ Checkpoint is a Point of synchronization between database and log file.
❖ Time to time (randomly or under some criteria) the database flushes its
buffer to database disk to minimize the task of recovery.
❖ When failure occurs, redo all transactions that committed since the
checkpoint and undo all transactions active at time of crash.
❖ In previous example ,Figure 2, on slide 6 , with checkpoint at time tc,
changes made by T2 and T3 have been written to secondary storage.
Thus: only redo T4 and T5, undo transactions T1 and T6.

15
VI. Checkpointing
❖Log file is used to recover failed DB but we may not know how far
back in the log to search. Thus
❖Checkpoint is a Point of synchronization between database and log
file.
❖Time to time (randomly or under some criteria) the database
flushes its buffer to database disk to minimize the task of recovery.
❖When failure occurs, redo all transactions that committed since the
checkpoint and undo all transactions active at time of crash.

16
VII. Transaction Roll-back (Undo) and Roll-Forward (Redo)
❖ If transaction fails for what so ever reason after updating the data base it
must be necessary to roll back
❖ If a transaction T is roll back , any transaction that has read the value of
some data item X written by T must be also be roll back
❖ Similarly once S is roll back, any transaction R that has read the values
of some data item Y written by S must aslo be roll back, and so on..
❖ To maintain such cases, 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. 17
Example

18
Roll-back: One execution of T1, T2 and T3 as recorded in the
log.

Remark:
• Only write item operation need to be undone during transaction roll back
• Read item operations are recorded in the log only to determine whether
cascading roll back of additional transaction is needed
19
2. Data Update and Recovery Scheme : Three types
i. 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.
▪ No undo is required because no AFIM is flushed to the disk before a
transaction commits.
▪ After reboot from a failure the log is used to redo all the transactions
affected by this failure.
– Limitation: out of buffer space may be happened because transaction
changes must be held in the cache buffer until the commit point
– Type of deferred updated recovery environment
▪ Single User and Multiple user environment
20
a) Deferred Update in a single-user system
▪ There is no concurrent data sharing in a single user system.
▪ 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.

21
22
 b) Deferred Update with concurrent users
▪ This environment requires some concurrency control mechanism to
guarantee isolation property of transactions.
▪ In a system recovery, transactions which were recorded in the log
after the last checkpoint were redone.
▪ The recovery manager may scan some of the transactions recorded
before the checkpoint to get the AFIMs.

▪T4 and T5 are ignored because they didn’t reach their commit points
▪T2 and T3 are redone because their commit point is after the last
checkpoint
23
▪ 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.
▪ Two tables are required for implementing this protocol:
▪ Active table: All active transactions are entered in this
table.
▪ Commit table: Transactions to be committed are entered in
this table.
▪ It is possible that a commit table transaction may be redone
twice but this does not create any inconsistency because of a
redone is “idempotent”,
▪ that is, one redone for an AFIM is equivalent to multiple
redone for the same AFIM.
24
ii. 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.

25
iii. Shadow Paging
❖ Maintain two page tables during life of a transaction: current page and
shadow page table.
❖ When transaction starts, two pages are the same.
❖ Shadow page table is never changed thereafter and is used to restore
database in event of failure.
❖ During transaction, current page table records all updates to database.
❖ When transaction completes, current page table becomes shadow page
table. X Y
X' Y'

Database
X and Y: Shadow copies of data items
X' and Y': Current copies of data items
26
▪ 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.

27
2.1 The ARIES Recovery Algorithm:
❖ The ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) recovery
algorithm is a widely used and influential recovery algorithm in database management
systems.
❖ It is designed to work with a steal , no- force approach
❖ It is based on: three principles
– WAL (Write Ahead Logging) : Any change to the database object is first
recorded in the log
• The record on the log must first be save on the disk and then
• The database object is written to disk
– 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.
• Transaction that were un committed at the time of crash are undone
– Logging changes during undo: It will prevent ARIES from repeating the
28
completed undo operations if a failure occurs during recovery, which causes a
restart of the recovery process.
IV. Data Update : Four types
– Deferred Update:
❖All transaction updates are recorded in the local workspace
(cache)
❖All modified data items in the cache is then written after a
transaction ends its execution or after a fixed number of
transactions have completed their execution.
❖During commit the updates are first recorded on the log and then
on the database
❖If a transaction fails before reaching its commit point undo is not
needed because it didn’t change the database yet
❖If a transaction fails after commit (writing on the log) but before
finishing saving to the data base redoing is needed from the log
29
– Immediate Update:
▪ As soon as a data item is modified in cache, the disk copy
is updated.
▪ These update are first recorded on the log and on the disk
by force writing, before the database is updated
▪ If a transaction fails after recording some change to the
database but before reaching its commit point , this will
be rolled back

30
– Shadow update:
▪ The modified version of a data item does not overwrite
its disk copy but is written at a separate disk location.
▪ Multiple version of the same data item can be maintained
▪ Thus the old value ( before image BFIM) and the new
value (AFIM) are kept in the disk
▪ No need of Log for recovery
– In-place update: The disk version of the data item is
overwritten by the cache version.

31
▪ Information for ARIES to accomplish recovery procedures includes:
❖ Log
❖ Transaction Table &
❖ Dirty page table
i. The Log and Log Sequence Number (LSN)
– The log is a history of actions executed by the DBMS in terms of a
file of records stored in disk for recovery purpose
– A unique LSN is associated with every log record
• LSN increases monotonically and indicates the disk address of
the log record it is associated with.
• In addition, each data page stores the LSN of the latest log
record corresponding to a change for that page.
32
– A log record is written for each of the following actions:
• updating a page
– After modifying the page , an update record is appended to
the log tail.
– The pageLSN of the page is then set to the LSN of the update
log record
• commit- when a transaction decides to commit , it force writes a
commit type log record containing the transaction id
• Abort- when a transaction is aborted , an abort type log
containing the transaction id is appended to the log
• End-when a transaction is aborted or committed , an end type log
record containing transaction id is appended to the log
• undo update- when transaction is roll back its updates are undone
33
 – A log record stores
• the previous LSN of that transaction
• the transaction ID
• the type of log record.
• For a write operation the following additional information is
logged:
• Page ID for the page that includes the item
• Length of the updated item
• Its offset from the beginning of the page
• BFIM of the item
ii. The Transaction table and the Dirty Page table
– For efficient recovery following tables are also stored in the log
during checkpointing:
• Transaction table: Contains an entry for each active
transaction, with information such as transaction ID,
transaction status( in progresses, committed or aborted) and the
LSN of the most recent log record for the transaction.
• Dirty Page table: Contains an entry for each dirty page in the
buffer, which includes the page ID and the LSN corresponding 34
to the earliest update to that page.
▪ Checkpointing
– A checkpointing does the following:
• Writes a begin_checkpoint record in the log
• Writes an end_checkpoint record in the log. With this
record the contents of transaction table and dirty page
table are appended to the end of the log.
• Writes the LSN of the begin_checkpoint record to a
special file. This special file is accessed during
recovery to locate the last checkpoint information.
– To reduce the cost of checkpointing and allow the system
to continue to execute transactions, ARIES uses “fuzzy
checkpointing”.

35
Recovering from System crash
• The following steps are performed
– Analysis phase:
• Start at the begin_checkpoint record and proceed to the
end_checkpoint record.
• Access transaction table and dirty page table are appended to
the end of the log.
• Note that during this phase some other log records may be
written to the log and transaction table may be modified.
• The analysis phase compiles the set of redo and undo to be
performed and ends.
– Redo phase: Starts from the point in the log up to where all dirty
pages have been flushed, and move forward to the end of the log.
Any change that appears in the dirty page table is redone.
– Undo phase: Starts from the end of the log and proceeds
backward while performing appropriate undo.
• The recovery completes at the end of undo phase.
36
37
 Question & Answer

2/10/2024 38
 Thanks !!!

2/10/2024 39