Advanced Database system

Chapter Five:
Database Recovery
Techniques
Prepared by:
Misganaw Abeje
University of Gondar
College Of Informatics
Department of computer science
[email protected]
1
 Outline

 Introduction
 Purpose of Database Recovery
 Types of failures
 Transaction Log
 Data Update
 Data Caching
 Write-Ahead Logging
 Check pointing
 Recovery Scheme/techniques
– Deferred Update (No Undo/Redo)

– Immediate Update (Undo/No-redo)

2
BY: MA – The ARIES Recovery Algorithm(undo/Redo)
 Introduction Database recovery

 Three states of Database:

– Pre-condition: At any given point in time the database is in a
consistent state.
– Condition: Some kind of system failure occurs
– Post-condition: Restore the database to the consistent state
that existed before the failure
 Database recovery is the process of restoring the
database to the most recent consistent state that existed
just before the failure.
 Database reliability: resilience of the database to
various types of failure and its capability to recover from
the failures.
3
BY: MA
 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 & and
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

4
BY: MA
 2. Types of failures

1. Transaction failure
 Erroneous parameter values
 Logical programming error
 System error like integer overflow, division by zero
 Local error like “data not found”
 User interrupt
 Concurrency control enforcement
2. System crash
 A hardware, software, or network error (also media failure)
3. Disk failure, and Catastrophe
5
BY: MA
  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
to restore to a consistent state and by keeping information about the
6 change in the system log.
BY: MA
 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 (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 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
7
7 T3 0 9 R N N = 400 N = 400
BY: MA T1 5 nil End
 4 Data Update Strategy
 There are different types of data update
1. Immediate Update: Whenever any transaction is executed, the updates
are made directly to the database and the log file is also maintained
which contains both old and new values.
– 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 , 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,
8
BY: MA
  2. Deferred Update: any transaction is executed, the
updates are not made immediately to the database. They
are first recorded on the log file and then those changes
are applied once the commit is done.
– 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, Hence, deferred update is also known as
the NO-UNDO/REDO algorithm.
9
BY: MA
 3. 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
4. In-place update: The disk version of the data item is
overwritten by the cache version.

10
BY: MA
 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.
 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) or FIFO
 While replacing buffers , first of all the updated value on that
buffer should be saved on the appropriate block in the data base
11
BY: MA
  Possible ways for flushing database cache to database disk:
1. No-Steal: Cache cannot be flushed before transaction commit.
2. 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
3. Force: if all Cache updates are immediately flushed (forced) to
disk before the transaction commits,
4. 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
12 I/O cost to read that page again ,
BY: MA
  These give rise to four different ways for handling recovery:
1. Steal/No-Force (Undo/Redo)
2. Steal/Force (Undo/No-redo)
3. No-Steal/No-Force (No-undo/Redo)
4. No-Steal/Force (No-undo/No-redo)
 Typical DB systems use a Steal/No-Force strategy because of:
1. Steal approach avoids the need for a very large buffer space to
store all updated pages in memory.
2. No-Force approach provides the advantage of keeping an
updated page of a committed transaction in the memory when
another transaction needs to update it, thus eliminates the I/O
cost of reading that page again from disk.
13
BY: MA
 6. Write-Ahead Logging (WAL)

 When in-place update (immediate or deferred) is used then log is

necessary for recovery.
 The process of recording the BFIM of the data items in the log and
enforcing the log to be recorded on disk before the BFIM is
overwritten by the AFIM in the DB on the disk is generally known as
WriteAhead Logging (WAL). 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.
14
BY: MA
  Database recovery is achieved either by performing only
Undo's or only Redo's or by a combination of the two. These
operations are recorded in the log as they happen.
 For example the <Ti, X, V1, V2> where Ti transaction, X
data item, V1 old value and V2 new value.
– Undo of a log record <Ti, X, V1, V2> writes the old value
V1 to X.
– Redo of a log record <Ti, X, V1, V2> writes the new
value V2 to X.

15
BY: MA
 7. Check pointing

 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. 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
16 appearing after [checkpoint] record.
BY: MA
17
BY: MA
 8. Recovery Scheme/techniques

1. 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.
– 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
18
BY: MA
 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.

19
BY: MA
 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.
 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.
 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.
 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
20 AFIM
BY: MA
 2. Recovery Techniques Based on Immediate Update

2.1. 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.

21
BY: MA
 2.2. Undo/Redo Algorithm (Single-user
environment)

 Recovery schemes of this category apply undo and also redo

for recovery. In a single-user environment no concurrency
control is required but a log is maintained under WAL.
 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.

22
BY: MA
 2.3. Undo/Redo Algorithm (Concurrent execution)

 Recovery schemes of this category applies undo and also redo

to recover the database from failure.
 In concurrent execution environment a concurrency control is
required and log is maintained under WAL.
 Commit table records transactions to be committed and active
table records active transactions.
 To minimize the work of the recovery manager check pointing
is used. The recovery performs:
– Undo of a transaction if it is in the active table.
– Redo of a transaction if it is in the commit table.
23
BY: MA
 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 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. is
never changed there after 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'
X and Y: Shadow copies of data items
Database
24 X' and Y': Current copies of data items
BY: MA
  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.

25
BY: MA
 3. The ARIES Recovery Algorithm
 Stands for “Algorithm for Recovery and Isolation Exploiting
Semantics.”
 It is designed to work with a steal , no- force/undo/redo approach, which
is based on the following three principles
1. 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

2. 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
26 undone
BY: MA
 3. 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.
Information for ARIES to accomplish recovery procedures
includes:
 Log
 Transaction Table &
 Dirty(updated) page table

27
BY: MA
 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.

28
BY: MA
  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 page LSN 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
29
BY: MA
  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
30
BY: MA
 ii. The Transaction table and the Dirty Page table
– For efficient recovery following tables are also stored in
the log during check pointing:
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 to the earliest update to that page.
31
BY: MA
  A check pointing 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 check-pointing and allow the system
to continue to execute transactions, ARIES uses “fuzzy
32 check-pointing”.
BY: MA
  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 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.
3. Undo phase: Starts from the end of the log and proceeds
backward while performing appropriate undo.
33  The recovery completes at the end of undo phase.
BY: MA
 Example of recovery in ARIES

34
BY: MA
  Thank you?

35