Scribd
Upload
61 views

Recovery Techniques

The document discusses database recovery techniques. It describes the purpose of recovery as bringing the database to its last consistent state before a failure. There are different types of failures including transaction failures, system failures, and media failures. The recovery strategy depends on the type of failure, and may involve undoing and redoing transactions to restore consistency. Checkpointing is used to minimize recovery efforts by periodically synchronizing the database and log files.

Uploaded by

Roha Cbc
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
61 views

Recovery Techniques

The document discusses database recovery techniques. It describes the purpose of recovery as bringing the database to its last consistent state before a failure. There are different types of failures including transaction failures, system failures, and media failures. The recovery strategy depends on the type of failure, and may involve undoing and redoing transactions to restore consistency. Checkpointing is used to minimize recovery efforts by periodically synchronizing the database and log files.

Uploaded by

Roha Cbc
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 10

CHAPTER 5

Recovery Techniques
Recovery Concepts
I. The Purpose of Database Recovery:
 To bring the database into the last consistent state, which existed prior
to the failure.
 To protect 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.
2
Recovery Concepts …
 Recovery from transaction failures usually means that the database is restored
to the most recent consistent state just before the time of failure.
 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(terrible)
 If there is extensive(general) damage to the wide portion of the
database
 This method restore a past copy of the database from the backup
storage.
 Recovery from non-catastrophic failure

 When the database is not physically damaged but has become


inconsistent
 The strategy uses undoing and redoing some operations in order to
restore to a consistent state.
3
Recovery Concepts …
 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.
Fig 2: status of
transactions at
the time of
system fails

– DBMS starts at time t0, but fails at time tf and tc is the last check point.
– T1 and T6 have to be undone.
– T2 and T3, no need of redo or undone
4
–
Recovery Concepts …
III. 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 checks 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
database 5
Recovery Concepts …
Two main strategies can be employed when flushing a
modified buffer back to disk.
i. Shadowing update:
 The modified version of a data item does not overwrite its
disk copy but is written at a separate disk location.
 Thus the old value ( before image BFIM) and the new value
(AFIM) are kept in the disk
ii. In-place updating: The disk version of the data item is
overwritten by the cache version.

6
Recovery Concepts …
 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
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

 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)
 No-Steal/Force (No-undo/No-redo)

7
Recovery Concepts …
VI. Check pointing
 Log file or record 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 , 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.
 The following steps defines a checkpoint operation:
i. Suspend execution of transactions temporarily.
ii. Force write modified buffer data to disk.
iii. Write a [checkpoint] record to the log, save the log to disk.
iv. Resume normal transaction execution.
8
Recovery Concepts …
VII. Transaction Roll-Back(Undo) and Roll-Forward(Redo)
 If a transaction fails for whatever reason after updating the database, it may
be necessary to roll back the transaction.
 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.
 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.
 This phenomenon is called cascading rollback

9
Thank You

Any Question???

10

You might also like