CoSc2072 : Advanced Database systems

Chapter Five:
Database Recovery Techniques

Department of Computer Science

College of Engineering and
Technology
Contents
• Recovery Concepts
• Recovery Concepts Based on Deferred Update
• Recovery Concepts Based on Immediate Update
• Shadow Paging
• The ARIES Recovery Algorithm
• Recovery in Multi database Systems
Recovery Concepts
• Recovery from transaction failures usually means that the database is restored to
the most recent consistent state before the time of failure.
• To do this, the system must keep information about the changes that were
applied to data items by the various transactions in the system log.
• Transaction failure may be either by catastrophic failure or Non-catastrophic
failure.
• For catastrophic failure the recovery method stores a past copy of the database
that was backed up to archival storage and reconstructs a more current state by
reapplying or redoing the operation of committed transactions from backed-up
log, up to the time of failure.
• When the database on Disk is not physically damaged the recovery strategy is to
identify any changes that may cause an inconsistency in the database.
Recovery Concepts…
• For non-catastrophic failure, the recovery protocol does not need a complete
archival copy of the database.
• We can distinguish two main policies for recovery from noncatastrophic
transaction failures:
• deferred update and
• immediate update.
Recovery Concepts…
• Deferred Update
• Do not physically update the database on disk until after a transaction commits; then the
updates are recorded in the database.
• Before reaching commit, all transaction updates are recorded in the local transaction
workspace or in the main memory buffers that the DBMS maintains.
• Before commit, the updates are recorded persistently in the log file on disk.
• Then after commit, the updates are written to the database from the main memory
buffers.
• If a transaction fails before reaching its commit point, it will not have changed the
database on disk 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 on
disk.
• Also known as the NO-UNDO/REDO algorithm.
Recovery Concepts…
• Immediate update
• The database may be updated by some operations of a transaction before the
transaction reaches its commit point.
• However, these operations must also be recorded in the log on disk by force-
writing before they are applied to the database on disk, making recovery still
possible.
• 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.
• The transaction must be rolled back.
• Both undo and redo may be required during recovery.
• Known as the UNDO/REDO algorithm.
Recovery Concepts…
• Two main strategies can be employed when flushing a modified buffer back to
disk.
in-place updating
• writes the buffer to the same original disk location.
• overwriting the old value of any changed data items on disk.
• a single copy of each database disk block is maintained
Shadowing
• writes an updated buffer at a different disk location
• so multiple versions of data items can be maintained
NB: In general, the old value of the data item before updating is called the
before image (BFIM), and the new value after updating is called the after image
(AFIM).
Write-Ahead Logging, Steal/No-Steal, and Force/No-Force
• When in-place updating is used, it is necessary to use a log for recovery
• 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
• Two types of log entry information included for a write command:
• the information needed for UNDO
• the information needed for REDO
• A REDO-type log entry includes the new value (AFIM) of the item written by
the operation.
• 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.
Standard DBMS recovery terminology
• no-steal approach - If a cache buffer page updated by a transaction
cannot be written to disk before the transaction commits.
• The no-steal rule means that UNDO will never be needed during
recovery.
• steal approach - if the recovery protocol allows writing an updated
buffer before the transaction commits.
• 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.
• force approach - If all pages updated by a transaction are immediately
written to disk before the transaction commits.
Standard DBMS recovery terminology…
• The force rule means that REDO will never be needed during recovery
• The deferred update (NO-UNDO) recovery scheme follows a no-steal
approach.
• However, typical database systems employ a steal/no-force (UNDO/REDO)
strategy.
• 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.
Checkpoints in the System Log
• Another type of entry in the log is called a checkpoint.
• A [checkpoint, list of active transactions] 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.
• all transactions that have their [commit, T ] entries in the log before [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.
• 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.
Transaction Rollback and Cascading Rollback
• If a transaction fails for whatever reason after updating the database, but
before the transaction commits, it may be necessary to roll back the
transaction.
• Cascading rollback:
• Is a situation in which when one transaction rolled back, the other
transaction that reads the value of some data item written by the
previous transaction is also rolled back and so on.
• 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.
• it can occur when the recovery protocol ensures recoverable schedules
but does not ensure strict or cascadeless schedules.
• can be complex and time-consuming.
NO-UNDO/REDO Recovery Based on Deferred Update
• The idea behind deferred update is to defer or postpone any
actual updates to the database on disk until the transaction
completes its execution successfully and reaches its commit point.
• If a transaction fails before reaching its commit point, there is no
need to undo any operations because the transaction has not
affected the database on disk in any way.
• only REDO type log entries are needed in the log, which include
the new value (AFIM) of the item written by a write operation.
• REDO is needed in case the system fails after a transaction
commits but before all its changes are recorded in
the database on disk.
NO-UNDO/REDO Recovery Based on Deferred Update

Typical deferred update protocol

• A transaction cannot change the database on disk until it
reaches its commit point; hence all buffers that have been
changed by the transaction must be pinned until the
transaction commits.
• A transaction does not reach its commit point until all its
REDO-type log entries are recorded in the log and the log
buffer is force-written to disk.
RDU_M (Recovery using Deferred Update in a Multiuser environment)
• For multiuser systems with concurrency control, the concurrency control and
recovery processes are interrelated.
• Procedure:
• Assuming that checkpoint entries are included in the log
• Use two lists of transactions maintained by the system:
• the committed transactions T since the last checkpoint (commit list), and
• the active transactions T’ (active list).
• REDO all the WRITE operations of the committed transactions from the log, in
the order in which they were written into the log.
• The transactions that are active and did not commit are effectively canceled
and must be resubmitted.
• REDO (WRITE_OP). Redoing a write_item operation WRITE_OP consists of
examining its log entry [write_item, T, X, new_value] and setting the value of
item X in the database to new_value, which is the after image (AFIM).
RDU_M (Recovery using Deferred Update in a Multiuser environment)
• An example of a recovery timeline to illustrate the effect of checkpointing.
RDU_M (Recovery using Deferred Update in a Multiuser environment)

• When the checkpoint was taken at time t1, transaction T1 had

committed, whereas transactions T3 and T4 had not.
• Before the system crash at time t2, T3 and T2 were committed but not
T4 and T5.
• According to the RDU_M method, there is no need to redo the
write_item operations of transaction T1—or any transactions
committed before the last checkpoint time t1.
• The write_item operations of T2 and T3 must be redone, however,
because both transactions reached their commit points after the last
checkpoint.
NO-UNDO/REDO Recovery Based on Deferred Update
• Drawback of Recovery Based on Deferred Update:
• It limits the concurrent execution of transactions because all write-locked
items remain locked until the transaction reaches its commit point.
• it may require excessive buffer space to hold all updated items until the
transactions commit.
• The method’s main benefit is that transaction operations never need to be
undone, for two reasons:
• A transaction does not record any changes in the database on disk until after
it reaches its commit point.
• A transaction will never read the value of an item that is written by an
uncommitted transaction, because items remain locked until a transaction
reaches its commit point.
• no cascading rollback will occur.
Recovery Techniques Based on Immediate Update
• when a transaction issues an update command, the database on disk
can be updated immediately, without any need to wait for the
transaction to reach its commit point.
• Provisions must be made for undoing the effect of update operations
that have been applied to the database by a failed transaction.
• This is accomplished by rolling back the transaction and undoing the
effect of the transaction’s write_item operations.
• The UNDO-type log entries, which include the old value (BFIM) of the
item, must be stored in the log.
• It follow a steal strategy for deciding when updated main memory
buffers can be written back to disk
Recovery Techniques Based on Immediate Update
• Two main categories of immediate update algorithms.
• 1st Method:
• If the recovery technique ensures that all updates of a transaction are
recorded in the database on disk before the transaction commits, there is
never a need to REDO any operations of committed transactions.
• This is called the UNDO/NO-REDO recovery algorithm.
• This method must utilize the steal/force strategy for deciding when updated
main memory buffers are written back to disk.
• 2nd Method:
• The transaction is allowed to commit before all its changes are written to the
database.
• known as the UNDO/REDO recovery algorithm.
• The steal/no-force strategy is applied.
Shadow Paging
• This recovery scheme does not require the use of a log in a single-
user environment.
• In a multiuser environment, a log may be needed for the
concurrency control method.
• Advanced recovery technique.
• Requires fewer disk access than log method.
• Maintain two page table during the life cycle of transaction.
• Current page table
• Shadow page table
• When the transaction starts both page table are identical.
Shadow Paging…
• All transactions are done on Current page table.
• Shadow page table never changed during transaction.
• All i/p and o/p operation are done on current page table to locate
database page on disk.
• Store shadow page table in non volatile storage.
• When transaction commits system writes current page table to non-
volatile storage. the current page table then become shadow page
table.
Shadow Paging…
• Advantages:
• Log record overhead is removed
• Faster recovery
• Drawback of shadow recovery:
• Commit overhead – in single transaction we find the actual data blocks,
current page table in disk address.
• Data fragmentation: updated data base pages change location on disk.
• if the directory is large, the overhead of writing shadow directories to
disk as transactions commit is significant.
• Garbage collection- when transaction commits database containing old
info cannot be accessed.
Shadow Paging…
The ARIES Recovery Algorithm
• ARIES:- Algorithm for Recovery and Isolation Exploiting Semantics.
• ARIES uses a steal/no-force type approach.
• It is based on three concepts:
• write-ahead logging,
• repeating history during redo, and
• logging changes during undo.
• repeating history, means that ARIES will retrace all actions of the database
system prior to the crash to reconstruct the database state when the crash
occurred. Transactions that were uncommitted at the time of the crash (active
transactions) are undone.
• logging during undo, will prevent ARIES from repeating the completed undo
operations if a failure occurs during recovery, which causes a restart of the
recovery process.
The ARIES Recovery Algorithm
• The ARIES recovery procedure consists of three main steps:
• Analysis step
• REDO step and
• UNDO step
• Analysis Phase:
• identifies the dirty (updated) pages in the buffer and the set of transactions active at the time
of the crash.
• The appropriate point in the log where the REDO operation should start is also determined.
• REDO Phase:
• actually reapplies updates from the log to the database.
• Certain information in the ARIES log will provide the start point for REDO, from which REDO
operations are applied until the end of the log is reached.
• Additionally, information stored by ARIES and in the data pages will allow ARIES to determine
whether the operation to be redone has actually been applied to the database and therefore
does not need to be reapplied.
The ARIES Recovery Algorithm…
• UNDO Phase:
• the log is scanned backward and the operations of transactions that were
active at the time of the crash are undone in reverse order.
• The information needed for ARIES to accomplish its recovery procedure includes
the log, the Transaction Table, and the Dirty Page Table. Additionally,
checkpointing is used.
• In ARIES, every log record has an associated log sequence number (LSN) that is
monotonically increasing and indicates the address of the log record on disk.
• Each LSN corresponds to a specific change (action) of some transaction.
• A log record is written for any of the following actions: updating a page (write),
committing a transaction (commit), aborting a transaction (abort), undoing an
update (undo), and ending a transaction (end).
Recovery in Multi database Systems
• Multi database transaction - a single transaction that access
multiple databases.
• These databases may even be stored on different types of
DBMSs;
• In such a case, each DBMS involved in the multi-database
transaction may have its own recovery technique and
transaction manager separate from those of the other DBMSs.
• To maintain the atomicity of a multi database transaction, it is
necessary to have a two-level recovery mechanism.
• A global recovery manager, or coordinator –
• local recovery managers -
Recovery in Multi database Systems…
• The coordinator usually follows a protocol called the two-phase commit protocol
• Phase 1:
• When all participating databases signal the coordinator that the part of the multi
database transaction involving each has concluded, the coordinator sends a
message prepare for commit to each participant to get ready for committing the
transaction.
• Each participating database receiving that message will force-write all log records
and needed information for local recovery to disk and then send a ready to
commit or OK signal to the coordinator.
• Phase 2:
• If all participating databases reply OK, and the coordinator’s vote is also OK, the
transaction is successful, and the coordinator sends a commit signal for the
transaction to the participating databases.
• if one or more of the participating databases or the coordinator have a not OK
response, the transaction has failed, and the coordinator sends a message to roll
back or UNDO the local effect of the transaction to each participating database.