Chapter 15: Recovery System Failure Classification Storage - PDF document

' $ Chapter 15: Recovery System • Failure Classification • Storage Structure • Recovery and Atomicity • Log-Based Recovery • Shadow Paging • Recovery With Concurrent Transactions • Buffer Management • Failure with Loss of Nonvolatile Storage • Advanced Recovery Techniques & % Database Systems Concepts 15.1 Silberschatz, Korth and Sudarshan c � 1997 ' $ Failure Classification • Transaction failure : – Logical errors: transaction cannot complete due to some internal error condition – System errors: the database system must terminate an active transaction due to an error condition (e.g., deadlock) • System crash: a power failure or other hardware or software failure causes the system to crash. It is assumed that non-volatile storage contents are not corrupted. • Disk failure: a head crash or similar failure destroys all or part of disk storage & % Database Systems Concepts 15.2 Silberschatz, Korth and Sudarshan c � 1997

' $ Storage Structure • Volatile storage: – does not survive system crashes – examples: main memory, cache memory • Nonvolatile storage: – survives system crashes – examples: disk, tape • Stable storage: – a mythical form of storage that survives all failures – approximated by maintaining multiple copies on distinct nonvolatile media & % Database Systems Concepts 15.3 Silberschatz, Korth and Sudarshan c � 1997 ' $ Stable-Storage Implementation • Maintain multiple copies of each block on separate disks; copies can be at remote sites to protect against disasters such as fire or flooding. • Failure during data transfer can result in inconsistent copies • Protecting storage media from failure during data transfer (one solution): – Execute output operation as follows (assuming two copies of each block): 1. Write the information onto the first physical block. 2. When the first write successfully completes, write the same information onto the second physical block. 3. The output is completed only after the second write & % successfully completes. Database Systems Concepts 15.4 Silberschatz, Korth and Sudarshan c � 1997

' $ Stable-Storage Implementation (Cont.) • Protecting storage media from failure during data transfer (cont.): – Copies of a block may differ due to failure during output operation. To recover from failure: 1. First find inconsistent blocks: (a) Expensive solution: Compare the two copies of every disk block. (b) Better solution: Record in-progress disk writes on non-volatile storage. Use this information during recovery to find blocks that may be inconsistent, and only compare copies of these. 2. If either copy of an inconsistent block is detected to have an error (bad checksum), overwrite it by the other copy. If both have no error, but are different, overwrite the second block by the first block. & % Database Systems Concepts 15.5 Silberschatz, Korth and Sudarshan c � 1997 ' $ Data Access • Physical blocks are those blocks residing on the disk. Buffer blocks are the blocks residing temporarily in main memory. • Block movements between disk and main memory are initiated through the following two operations: – input ( B ) transfers the physical block B to main memory. – output ( B ) transfers the buffer block B to the disk, and replaces the appropriate physical block there. • Each transaction T i has its private work-area in which local copies of all data items accessed and updated by it are kept. T i ’s local copy of a data item X is called x i . • We assume, for simplicity, that each data item fits in, and is stored inside, a single block. & % Database Systems Concepts 15.6 Silberschatz, Korth and Sudarshan c � 1997

' $ Data Access (Cont.) • Transaction transfers data items between system buffer blocks and its private work-area using the following operations : – read ( X ) assigns the value of data item X to the local variable x i . – write ( X ) assigns the value of local variable x i to data item X in the buffer block. – both these commands may necessitate the issue of an input ( B X ) instruction before the assignment, if the block B X in which X resides is not already in memory. • Transactions perform read ( X ) while accessing X for the first time; all subsequent accesses are to the local copy. After last access, transaction executes write ( X ). • output ( B X ) need not immediately follow write ( X ). System can & % perform the output operation when it deems fit. Database Systems Concepts 15.7 Silberschatz, Korth and Sudarshan c � 1997 ' $ Example of Data Access global buffer A read( A ) B A actual write( B ) B read( A ) write( B ) A A B local buffer local buffer T 1 T 2 memory disk & % Database Systems Concepts 15.8 Silberschatz, Korth and Sudarshan c � 1997

' $ Recovery and Atomicity • Consider transaction T i that transfers $50 from account A to account B ; goal is either to perform all database modifications made by T i or none at all. • Several output operations may be required for T i (to output A and B ). A failure may occur after one of these modifications have been made but before all of them are made. • To ensure atomicity despite failures, we first output information describing the modifications to stable storage without modifying the database itself. • We study two approaches: – log-based recovery , and – shadow-paging • We assume (initially) that transactions run serially, that is, one & % after the other. Database Systems Concepts 15.9 Silberschatz, Korth and Sudarshan c � 1997 ' $ Log-Based Recovery • A log is kept on stable storage. The log is a sequence of log records , and maintains a record of update activities on the database. • When transaction T i starts, it registers itself by writing a < T i start > log record • Before T i executes write ( X ), a log record < T i , X, V 1 , V 2 > is written, where V 1 is the value of X before the write, and V 2 is the value to be written to X . • When T i finishes it last statement, the log record < T i commit > is written. • We assume for now that log records are written directly to stable storage (that is, they are not buffered) & % Database Systems Concepts 15.10 Silberschatz, Korth and Sudarshan c � 1997

' $ Deferred Database Modification • This scheme ensures atomicity despite failures by recording all modifications to log, but deferring all the write s to after partial commit. • Assume that transactions execute serially • Transaction starts by writing < T i start > record to log. • A write ( X ) operation results in a log record < T i , X, V > being written, where V is the new value for X . The write is not performed on X at this time, but is deferred. • When T i partially commits, < T i commit > is written to the log • Finally, log records are used to actually execute the previously deferred writes. & % Database Systems Concepts 15.11 Silberschatz, Korth and Sudarshan c � 1997 ' $ Deferred Database Modification (Cont.) • During recovery after a crash, a transaction needs to be redone if and only if both < T i start > and < T i commit > are there in the log. • Redoing a transaction T i ( redo ( T i )) sets the value of all data items updated by the transaction to the new values. • Crashes can occur while the transaction is executing the original updates, or while recovery action is being taken • example transactions T 0 and T 1 ( T 0 executes before T 1 ): T 0 : read ( A ) T 1 : read ( C ) A := A − 50 C := C − 100 write ( A ) write ( C ) read ( B ) B := B + 50 write ( B ) & % Database Systems Concepts 15.12 Silberschatz, Korth and Sudarshan c � 1997

' $ Deferred Database Modification (Cont.) • Below we show the log as it appears at three instances of time. < T 0 start > < T 0 start > < T 0 start > < T 0 , A, 950 > < T 0 , A, 950 > < T 0 , A, 950 > < T 0 , B, 2050 > < T 0 , B, 2050 > < T 0 , B, 2050 > < T 0 commit > < T 0 commit > < T 1 start > < T 1 start > < T 1 , C, 600 > < T 1 , C, 600 > < T 1 commit > (a) (b) (c) • If log on stable storage at time of crash is as in case: (a) No redo actions need to be taken (b) redo ( T 0 ) must be performed since < T 0 commit > is present (c) redo ( T 0 ) must be performed followed by redo ( T 1 ) since < T 0 commit > and < T 1 commit > are present & % Database Systems Concepts 15.13 Silberschatz, Korth and Sudarshan c � 1997 ' $ Immediate Database Modification • This scheme allows database updates of an uncommitted transaction to be made as the writes are issued; since undoing may be needed, update logs must have both old value and new value • Update log record must be written before database item is written • Output of updated blocks can take place at any time before or after transaction commit • Order in which blocks are output can be different from the order in which they are written. & % Database Systems Concepts 15.14 Silberschatz, Korth and Sudarshan c � 1997