Database Recovery Techniques

Advanced Database Systems

Database Recovery
 Database recovery is the process of restoring database to a correct
state in the event of a failure.
 A database recovery is the process of eliminating the effects of a
failure from the database.
 Recovery, in database systems terminology, is called restoring the last
consistent state of the data items.
 Need for Recovery Control
 Two types of storage: volatile (main memory) and nonvolatile.
 Volatile storage does not survive system crashes.
 Stable storage represents information that has been replicated in several
nonvolatile storage media with independent failure modes.
Types of failures

 A failure is a state where data inconsistency is visible to

transactions if they are scheduled for execution. The kind of
failure could be:
 System crashes, resulting in loss of main memory.
 Media failures, resulting in loss of parts of secondary storage.
 Application software errors.
 Natural physical disasters.
 Carelessness or unintentional destruction of data or facilities.
 Sabotage.
Types of failures
In databases usually a failure can generally be categorized as one of the following
major groups:
1. Transaction failure: a transaction cannot continue with its execution, therefore,
it is aborted and if desired it may be restarted at some other time. Reasons:
Deadlock, timeout, protection violation, or system error.
2. System failure: the database system is unable to process any transactions. Some
of the common reasons of system failure are: wrong data input, register overflow,
power failure, memory failure, etc.
3. Media failure: failure of non-volatile storage media (mainly disk). Some of the
common reasons are: head crash, dust on the recording surfaces, fire, etc.
Types of failures
 The basic steps in performing a recovery are
1. Isolating the database from other users. Occasionally, you may need to drop
and re-create the database to continue the recovery.
2. Restoring the database from the most recent useable dump.
3. Applying transaction log dumps, in the correct sequence, to the database to
make the data as current as possible.
 One can recover databases after three basic types of problems: user
error, software failure, and hardware failure.
 In a transaction recovery, the effect of failed transaction is removed
from the database, if any.
Types of failures (Example)
 The initial value of A=100, B=200 and C=300
 The Required state after the execution of T1 is A=500, B=800 and
C=700
Types of failures (Example)
Transactions and Recovery
 Transactions represent basic unit of recovery.
 Recovery manager responsible for atomicity and durability.
 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.
 Partial undo - only one transaction has to be undone.
 Global undo - all transactions have to be undone.
Recovery Facilities
DBMS should provide following facilities to assist with recovery:
 Backup mechanism: that makes periodic backup copies of database.
 Logging facility: that keeps track of current state of transactions and database
changes.
 Checkpoint facility: that enables updates to database in progress to be made
permanent.
 Recovery manger: This allows the DBMS to restore the database to a consistent
state following a failure.
Restoring the database means transforming the state of the database to the
immediate good state before the failure.
To do this, the change made on the database should be preserved. Such kind of
information is stored in a system log or transaction log file.
Log File
 Contains information about all updates to database:
• Transaction records.
• Checkpoint records.
 Often used for other purposes (for example, auditing).
Transaction records contain:
 Transaction identifier.
• Type of log record, (transaction start, insert, update, delete, abort, commit).
• Identifier of data item affected by database action (insert, delete, and update operations).
 Log management information.
 Log file sometimes split into two separate random-access files.
 Potential bottleneck; critical in determining overall performance.
Check Point
 Checkpoint: is a point of synchronization between database and log file. All
buffers are force-written to secondary storage.
 Checkpoint record is created containing identifiers of all active transactions.
 When failure occurs, redo all transactions that committed since the checkpoint and
undo all transactions active at time of crash.
Recovery Technique
If database has been damaged:
 Need to restore last backup copy of database and reapply updates of committed
transactions using log file.
 Extensive damage/catastrophic failure: physical media failure; is restored by using
the backup copy and by re executing the committed transactions from the log up to
the time of failure.
If database is only inconsistent:
 No physical damage/only inconsistent: the restoring is done by reversing the
changes made on the database by consulting the transaction log.
 Need to undo changes that caused inconsistency. May also need to redo some
transactions to ensure updates reach secondary storage.
 Do not need backup, but can restore database using the log file.
Recovery Techniques for Inconsistent Database State
 Recovery is required if only the database is updated. The kind of recovery also
depends on the kind of update made on the database.
 Database update: A transaction‘s updates to the database can be applied in two
ways:

 Three main recovery techniques:

1. Deferred Update
2. Immediate Update
3. Shadow Paging
Deferred Update
 Updates are not written to the database until after a transaction has reached its
commit point.
 If transaction fails before commit, it will not have modified database and so no
undoing of changes required.
 May be necessary to redo updates of committed transactions as their effect may
not have reached database.
 If a transaction aborts, ignore the log record for it. And do nothing with transaction
having a transaction start‖ and Transaction abort‖ log records.
 The redo operations are made in the order they were written to log.
Immediate Update/ Update-In-Place
 Updates are applied to database as they occur.
 Need to redo updates of committed transactions following a failure.
 May need to undo effects of transactions that had not committed at time of
failure.
 Essential that log records are written before write to database. Write ahead log
protocol.
 If no "transaction commit" record in log, then that transaction was active at failure
and must be undone.
Immediate Update/ Update-In-Place
 As soon as a transaction updates a data item, it updates the final copy of the
database on the database disk.
 During making the update, the change will be recorded on the transaction log to
permit rollback operation in case of failure.
 UNDO and REDO are required to make the transaction consistent. Thus it is
called UNDO/REDO Algorithm.
 This algorithm will undo all updates made in place before commit.
 The redo is required because some operations which are completed but not
committed should go to the database.
 If we don‘t have the second scenario, then the other variation of this algorithm is
called UNDO/NO-REDO Algorithm.
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.
 No log record management
 However, it has an overhead of managing pages i.e. page replacement issues have
to be handled.
The ARIES Recovery Algorithm
Algorithm for Recovery and Isolation Exploiting Semantics (ARIES) is based on the
Write Ahead Log (WAL) protocol.
1.Undo-only log record:
Only the before image is logged. Thus, an undo operation can be done to retrieve
the old data.
2.Redo-only log record:
Only the after image is logged. Thus, a redo operation can be attempted.
3.Undo-redo log record:
Both before images and after images are logged.
Recovery in Multi database Systems (Reading)