Database Recovery PDF

Database Recovery
Dr. Neetu Narwal

Asso. Prof. BCA[M]
Prepared by : Dr. Neetu Narwal

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.
 This information is kept in System log.

 If there is extensive damage due to catastrophic failure, the recovery
method restores the past copy of the database that was backed up to
archival storage
 For non-catastrophic failure, the recovery strategy is to identify any
changes that may cause inconsistency in the database.
 Like a transaction that has updated some of the item in the database but
has not been committed, needs to undo the write operations. It may be
necessary to redo some operations in order to restore a consistent state.

Two main policies for recovery from
non-catastrophic failures
 Deferred update –this technique do not update the database on disk until
a transaction is committed.
 No undo needed.
 This algorithm is known as NO-UNDO/REDO algorithm.
 Immediate update – this technique immediately write on the database
before the transaction reaches its commit point.
 No redo needed.
 This algorithm is known as UNDO/NO-REDO algorithm. In some case
UNDO/REDO algorithm.

 The old value of the data item before updating is called Before
image(BFIM).
 The new value after updating is called the After image (AFIM).
 There are two types of log entry information included for a write command:
 1) The information needed for UNDO.
 2) The information needed for REDO.
 A REDO type log entry includes the new value (AFIM) of the item written by
the operation since this is needed to redo the effect of the operation from
the log.
 A UNDO type log entry includes 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
 If a cache buffer page updated by a transaction cannot be written to disk

before the transaction commits, the recovery method is called no-steal
approach.
 If the method allows writing an updated buffer before the transaction
commits, it is called steal.
 If all pages updated by transaction are immediately written to disk before
the transaction commits, the recovery approach is called force approach.
 Otherwise it is called no-force.

 Deferred update recovery scheme follows no-steal approach.
 Typical database system employs steal/no-force (UNDO/REDO) strategy.
 Immediate update recovery scheme follows force approach.

Checkpoints
 A special type of entry in the log is called Checkpoint.

 A Checkpoint is a record written into the log periodically at that point when
system writes to the database all DBMS buffer that have been modified.
 As a result the transactions that have their commit entries in the log before
the checkpoint needed not be redone in case of system crash.
 Since all the updates are recorded in the database during checkpoint.
 The recovery manager must decide at what interval to take checkpoint.

Checkpoint consist of following actions
1. Suspend execution of transaction temporarily.

2. Force-write all main memory buffers that have been modified to disk.
3. Write a [checkpoint] record to the log, and force-write the log to disk.
4. Resume executing transactions.

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.
 The undo-type log entry is used to restore to their previous image(BFIM).
 If transaction T is rolled back, any transaction that read the value of some
data item X must also be rolled back and so on.
 This phenomenon is called cascading rollback.

NO-UNDO/REDO Recovery Based on
Deferred Update
 During transaction execution, the updates are recorded only in the log and
in the cache buffer.
 After the transaction reached its commit point, the log is force-written to
disk, the updates are recorded in the database.
 If transaction fails before reaching its commit point, there is no need to
undo any operation as it has not affected the database.
 Only REDO type log entries are needed in the log, which include the new
value (AFIM).
 The undo-type log entries are not needed since no undoing is required.

Recovery Technique based on
Immediate Update
 When a transaction issues an update command, the database on disk can
be updated immediately, without need to wait for the transaction to reach
its commit point.
 If a transaction fails later their effect must be undone.
 This is done by rolling back the transaction and undoing the effect of the
transaction write-item operation.
 Therefore UNDO-type log entry is required which include old value BFIM of
the item.

Shadow Paging
 The recovery scheme does not require the use of a log in a single-user
environment.
 In multi-user environment, a log may be needed for the concurrency
control method.
 Shadow paging considers the database to be made up of a number of
fixed size disk pages for recovery purpose.

 When a transaction begins executing, the current directory- whose entries
point to the most recent or current database pages on disk- is copied into
a shadow directory.
 The shadow directory is saved on disk while the current directory is used by
the transaction.
 During transaction execution, the shadow directory is never modified.
 When write-item operation is performed, a new copy of the modified
database page is created, but the old copy of that page is not
overwritten.
 The new page is written on some unused disk block.

 The current directory entry is modified to point to the new disk block,
whereas the shadow directory is not modified and continue to point to the
old unmodified disk block.
 The old version is referenced by shadow directory.
 The new version is referenced by current directory.

 To recover from a failure during transaction execution, it is sufficient to free
the modified database pages and discard the current directory.
 The state of database before transaction execution is available through
the shadow directory and the state is received by reinstating the shadow
directory.
 Committing a transaction corresponds to discard the previous shadow
directory.
 Since recovery involves neither undoing nor redoing data items, this
technique is called NO-UNDO/NO-REDO technique for recovery.

Database Recovery PDF

Uploaded by

Copyright:

Available Formats

Database Recovery PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Database Recovery PDF

Uploaded by

Copyright:

Available Formats

Database Recovery

Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

 Recovery from transaction failures usually means that the database is

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

 If a cache buffer page updated by a transaction cannot be written to disk

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

 A special type of entry in the log is called Checkpoint.

Prepared by : Dr. Neetu Narwal

1. Suspend execution of transaction temporarily.

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

Prepared by : Dr. Neetu Narwal

You might also like