Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

4.
<ul><li>Recovery from transaction failures means that the database is restored to the most recent consistent state just before the time of failure. </li></ul><ul><li>System must keep information that enables recovery from failures. </li></ul><ul><li>A typical strategy for recovery includes: </li></ul><ul><ul><li>If database is physically damaged (e.g., disk crash), then recovery method restores a past copy of the database. </li></ul></ul><ul><ul><li>Recovery from non-catastrophic (transaction) failures may imply a redo/undo of some operations (this can be done by information kept in the system log ). </li></ul></ul>Recovery Concepts

5.
<ul><li>Writing and reading to secondary storage is a performance bottleneck. To increase performance, the DBMS maintains a collection of in-memory buffers, called the DBMS cache . </li></ul><ul><li>A directory is used to keep track of which database items are in the buffers (cache). </li></ul><ul><li>When the DBMS requests action on some item, it first checks the cache directory. If it is not in the cache, then the appropriate disk pages must be copied into the cache. </li></ul><ul><li>A dirty bit (associated with each buffer), indicates whether or not the buffer has been modified. </li></ul><ul><li>A negative aspect of caching is that is makes recovery from failure more complex. </li></ul>Caching (Buffering) of Disk Blocks

6.
<ul><li>It may be necessary to replace (or flush) some of the cache buffers to make space available for the new item. </li></ul><ul><li>Two main strategies for flushing a modified buffer: </li></ul><ul><ul><li>In-place updating: writes the buffer back to the same original disk location (overwriting old values). </li></ul></ul><ul><ul><li>Shadowing: writes an updated buffer at a different disk location. Multiple versions of the data can be maintained. </li></ul></ul>Caching (Buffering) of Disk Blocks

7.
<ul><li>The old value of a data item before updating is called the before image (BFIM) , and the new value after updating is called the after image (AFIM). </li></ul><ul><li>The shadowing strategy can keep both the BFIM and the AFIM for recovery. </li></ul><ul><li>In-place updating requires use of a log for recovery. The BFIM of an updated item must be recorded in the log before BFIM is overwritten with the AFIM (this is known as write-ahead logging ). </li></ul><ul><li>Two types of log entry information include: </li></ul><ul><ul><li>Information needed for UNDO; contains the old value (BFIM) of the item, </li></ul></ul><ul><ul><li>Information needed for REDO; contains the new value (AFIM) of the item. </li></ul></ul>Caching (Buffering) of Disk Blocks

8.
<ul><li>If a buffer needs to be reused, but it has data written by a transaction that has not committed: </li></ul><ul><ul><li>A steal approach writes the data anyway so the buffer can be reused ― i.e. the buffer is stolen </li></ul></ul><ul><ul><li>A no-steal approach does not allow the data to be written until the transaction commits </li></ul></ul><ul><li>When a transaction commits: </li></ul><ul><ul><li>In a force approach , all buffers updated by a transaction are immediately written to disk </li></ul></ul><ul><ul><li>In a no-force approach , they could be written later </li></ul></ul>Caching (Buffering) of Disk Blocks

9.
<ul><li>Checkpoint is also a type of entry in the log. It is written into the log when the system writes out to the database on disk all DBMS buffers that have been modified. </li></ul><ul><li>All transactions that have their [COMMIT, T] entries in the log before a checkpoint entry, do not need to have their WRITE operations REDONE in case of a system crash. </li></ul><ul><li>The recovery manager of a DBMS must decide at what intervals to take a checkpoint. </li></ul>Checkpoints in the system log

10.
<ul><li>Taking a checkpoint consists of the following actions: </li></ul><ul><ul><li>Suspend execution of transactions temporarily, </li></ul></ul><ul><ul><li>Force-write all main memory buffers that have been modified to disk, </li></ul></ul><ul><ul><li>Write a [CHECKPOINT] record to the log, and force-write the log to disk. </li></ul></ul><ul><ul><li>Resume execution of transactions. </li></ul></ul>Checkpoints in the system log

11.
<ul><li>If a transaction fails for whatever reason after updating the database, it may be necessary to roll back the transaction. </li></ul><ul><li>Also a transition may need to be roll back because of cascading rollback phenomenon. </li></ul><ul><li>In practice, cascading rollback of transactions is never required because practical recovery methods guarantee cascadeless or strict schedules. </li></ul>Transaction Rollback

14.
<ul><li>Some approaches for recovery from non-catastrophic (transaction) failures can be classified as either: </li></ul><ul><li>Deferred update: (NO-UNDO, REDO) </li></ul><ul><ul><li>The database is not physically updated until after a transaction reaches its commit point. </li></ul></ul><ul><ul><li>UNDO is not needed </li></ul></ul><ul><ul><li>REDO may be necessary </li></ul></ul><ul><li>Immediate update: (UNDO, NO-REDO) </li></ul><ul><ul><li>The database is physically updated before the transaction reaches to its commit point. </li></ul></ul><ul><ul><li>UNDO may be necessary when a transaction fails </li></ul></ul><ul><ul><li>REDO is not needed. </li></ul></ul>Recovery Techniques

15.
<ul><li>A deferred update method can be classified as a no-steal approach. It obey the following rules: </li></ul><ul><ul><li>A transaction cannot change the database on disk until it reaches its commit point, </li></ul></ul><ul><ul><li>A transaction does not reach its commit point until all its update operations are recorded in the log and the log is force-written to disk. </li></ul></ul><ul><ul><li>Because the database is never updated on disk until after the transaction commits, there is never the need to UNDO any operations (that is why a deferred update is known as NO-UNDO/REDO recovery algorithm ). </li></ul></ul>Recovery Techniques Based on Deferred Update

16.
<ul><li>Recovery using deferred update in a single user environment uses the following procedure: </li></ul><ul><li>PROCEDURE RDU: </li></ul><ul><ul><li>apply the REDO operation to all the WRITE_ITEM operations of the committed transactions from the log in the order in which they were written to the log. </li></ul></ul><ul><ul><li>Restart the active transactions. </li></ul></ul><ul><li>The REDO operation must be idempotent – that is, executing it over and over is equivalent to executing it just once. </li></ul>Recovery Techniques Based on Deferred Update

17.
<ul><li>FIGURE 19.2 An example of recovery using deferred update in </li></ul><ul><li>a single-user environment. </li></ul><ul><li>The READ and WRITE operations of two transactions. </li></ul><ul><li>The system log at the point of crash. </li></ul>Recovery Techniques Based on Deferred Update

20.
<ul><li>In immediate update techniques, although the database can be updated immediately, update operations must be recorded in the log (on disk) before being applied to the database. </li></ul><ul><li>There is never a need to REDO any operations of committed transactions (this is called the UNDO/NO-REDO recovery algorithm ). </li></ul><ul><li>The effect of all active transactions at the time of failure must be undone. </li></ul>Recovery Techniques Based on Immediate Update

21.
<ul><li>Recovery using immediate update uses the following recovery procedure: PROCEDURE RIU: </li></ul><ul><ul><li>UNDO all the WRITE_ITEM operations of the active (uncommitted) transactions from the log. The operations should be done in the reverse of the order in which they were written into the log. </li></ul></ul><ul><ul><li>Restart the active transactions. </li></ul></ul>Recovery Techniques Based on Immediate Update

22.
<ul><li>Shadow Paging is a NO-UNDO, NO-REDO approach to recovery. </li></ul><ul><li>In a single-user environment, does not require the use of a log. In a multiuser environment, a log may be needed for the concurrency control method. </li></ul><ul><li>It considers the database to be made up of a number of fixed-size disk pages (located in the main memory). </li></ul><ul><li>When a transactions begins it creates its own current and shadow directories </li></ul><ul><li>When a WRITE_ITEM operation is performed, a new copy of the modified DB page is created and the current directory is modified </li></ul><ul><li>Recovery from a failure requires freeing the modified pages and discarding the current directory. </li></ul>Shadow Paging

24.
<ul><li>ARIES is a REDO/UNDO approach to recovery, steal/no-force approach for writing </li></ul><ul><li>Recovery procedure has three main phases: </li></ul><ul><ul><li>Analysis phase: identifies the dirty (updated) pages in the buffer, and the set of active transactions. Finds where in the log to begin REDO. </li></ul></ul><ul><ul><li>REDO phase: reapplies updates from the log in order to bring the database to the state it was in before failure. </li></ul></ul><ul><ul><li>UNDO phase: the log is scanned backwards and the operations of transactions that were active at the time of the crash are undone in reverse order. </li></ul></ul>The ARIES Recovery Algorithm

26.
<ul><li>A multidatabase transaction is a transaction that requires access to multiple databases. </li></ul><ul><li>A global recovery manager (or coordinator ) performs the two-phase commit protocol : </li></ul><ul><ul><li>When all participating databases signal the coordinator that the part of the multidatabase transaction involving each has concluded, the coordinator sends a message “prepare for commit” to each participant, </li></ul></ul><ul><ul><li>If all participating databases reply “OK”, the transaction is successful and the coordinator sends a “commit” signal to the participating databases; otherwise it sends a message “roll back” or UNDO the local effect of the transaction to each participating database. </li></ul></ul>Recovery in Multidatabase Systems

27.
<ul><li>A key assumption in our discussion of non-catastrophic failures has been that the system log is maintained on the disk and is not lost as a result of the failure. </li></ul><ul><li>The recovery manager of a DBMS must also be equipped to handle catastrophic failures. </li></ul><ul><li>The main technique used to handle catastrophic failures (such as disk crashes) is that of database backup. Hence, the whole database and the log are periodically copied onto a cheap storage medium such as magnetic tapes (in case of a catastrophic failure, the latest backup copy can be reloaded). </li></ul>Recovery from Catastrophic Failures