CS 2550 / Spring 2006 Principles of Database Systems Undo/No-Redo - PowerPoint PPT Presentation

Recovery Techniques and Assumptions  Undo/Redo Algorithm CS 2550 / Spring 2006  Principles of Database Systems  Undo/No-Redo   No-Undo/Redo (also called logging with deferred updates )  14 – Recovery Algorithms  No-Undo/No-Redo (also called shadowing )  Alexandros Labrinidis University of Pittsburgh 2 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Recovery Techniques and Assumptions Undo/Redo Recovery Algorithm All the techniques assume the following: The following types of log records are used: Failures are detectable. Commit, Abort record: [ T i , commit]  [ T i , abort] Write operations are atomic(i.e., execute either in its entirety or  Update record, U i : [ T i , x, b, a, old-LSN(x), prev-LSN( T i )] not at all). If this is not the case, we consider this failure as media failure T i : the id of the transaction that issued the Write  x: the address of the block being modified and the offset and length b: the before image of the modified portion of the block The scheduler sends operations to DM in an order which produces  executions that are correct and strict a: the after image of the modified portion of the block old-LSN(x): the LSN of x's buffer before this update No media failure prev-LSN( T i ): the LSN of the preceding log record of this transaction  (null if it's the first) Checkpoint record: [ CP id , Ac] The granularity of Writes that DM processes is the same as the  that of the atomic Write supported by the hardware.  Ac: a list of the active transactions at checkpoint time. 3 4 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 1

Undo/Redo Operations Undo/redo Operations (cont'd)  RM-Read( T i ,x)  RM-Abort( T i )  return BM-Read(x)  Let U i be the LSN of the most recent update record of T i ,  RM-Commit( T i ) U i : [ T i , x, b, a, old-LSN), prev-LSN]  Append [ T i , commit] to log and flush all log buffers  While U i ≠ null do:  Send ack to the scheduler  Fix(x) in buffers  RM-Write( T i , x, a )  BM-Write( x, b )  Fix(x) in buffers  Set LSN(x) = old-LSN  Append the record U i to the log buffer:  Unfix( x ) [ T i , x, b, a, old-LSN(x) = LSN( x ), prev-LSN( T i )]  U i = prev-LSN  Set LSN( x ) = U i  BM-Write( x, a ) and Unfix( x )  Append [ T i , abort] to the log and send ack to the scheduler  ack ( W i ) to the scheduler 5 6 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Fuzzy Checkpointing: Stable-LSN Fuzzy Checkpointing Algorithm  We attach the Stable-LSN field to each buffer block.  Stop accepting new operations (active transactions are   Stable-LSN is the LSN of the last record in the log buffer blocked). when the data item presently occupying the buffer was last  read CP-LSN (the LSN of the latest checkpoint). fetched or flushed.   Scan the buffer pool and for each dirty buffer whose  Stable-LSN describes the time at which a block and its  Stable-LSN is less than CP-LSN do: corresponding disk block in stable storage are the same. Flush all log records whose LSN is less than the buffer's block-LSN.  page dirty fix block Stable buffer Flush this buffer. Id Bit count LSN LSN number  name Set Stable-LSN of this buffer to be the CP-LSN of the new  x 0 0 812 805 0 checkpoint record (that will be written at the end of this process). y 1 2 10 7 1 2 0 1 123 123 2 7 8 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Buffer Table 2

Fuzzy Checkpointing Algorithm Restart Algorithm with Fuzzy Checkpoint  Set CL = ∅ and AL = ∅ .  Starting from [CP-LSN, Ac ], scan the log forward.    Read the log backwards , until the penultimate checkpoint For each commit or abort record for T i , do   record is reached, and for each record do: Ac = Ac - { T i }. If [ T i , commit ], then CL = CL U { T i }. For each update record for T , do Ac = Ac U { T i }.   If [ T i , abort ], then AL = AL U { T i }.   Append a checkpoint record to the log buffer with the  If [ T i , x, b, a , old-LSN, prev-LSN], then  active list Ac , and flush this buffer.  If T i ∈ CL then ignore this record else AL = AL U { T i }  Write the new CP-LSN to the predefined location.  If T i ∈ AL then   Resume normal execution. BM-Write( x, b )  LSN( x ) = old-LSN( U ) if prev-LSN = null then AL = AL - { T i } If it is the latest checkpoint record then ignore it.  9 10 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Restart Algorithm with Fuzzy Checkpoint How to avoid Unnecessary Writes?  Add in AL all T i 's in Ac of penultimate checkpoint but  not in CL .  Store LSN's in the block header. At restart, use the LSN to find out exactly which updates in the log have  Proceed backwards, until AL = ∅ , and for each update  record U already been moved to disk. If T i in AL then  issue BM-Write( x, b ). No need to redo these updates! if prev-LSN( U) = null then AL = AL - { T i }.  Starting from the penultimate checkpoint record  proceed forward For each update record such that T i ∈ CL issue BM-Write( x, a ).   Send ack to the scheduler.  11 12 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 3

Restart: Backward Scanning Restart: Forward Scanning For each update record U: [ T, x , operation, old-LSN, prev-LSN] of an Start from the penultimate checkpoint record and proceed forward.   uncommitted transaction (aborted or active at system crash) do: Read the block of x in main and examine the LSN( x ).  For each update record U: [ T, x, operation, old-LSN, prev-LSN] of a  if LSN( x ) < LSN( U ) /* the update described in U did not committed transaction T i , examine the LSN( x ). do nothing make it to stable storage */ else if LSN( x ) = LSN( U ) /* U describes the operation on x */ if LSN( x ) < LSN( U ) /* the update described in U didn't LSN( x ) = old-LSN( U ); redo(operation); make it to the stable storage. */ undo(operation); else if LSN( x ) = LSN( U ) /* the update described in U on x is else /* LSN( x ) > LSN( U ) */ do nothing. already in the stable database. */ else /* LSN( x ) > LSN( U ) */ /* there should be another log record do nothing; do nothing; after U that describes the update on x .*/ /* x contains an update by a log record U' appearing after U; implies that the transaction that produced U' must have committed */ 13 14 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Discussion Undo/No-Redo Recovery Algorithm  It never requires redoing an update.  Strong interaction between concurrency and recovery systems.  Basically the same as the previous algorithm except the commit operation.  The locking granularity must be at least as coarse as the  Commit( T i ) recovery granularity.  for each x updated by T i flush x 's buffer to stable storage. Example :  add a commit record to the log.  If the recovery granularity is a block/page we can not have record  Restart level locking.  Restart requires one (backward) scan through the log.  If the recovery granularity is a record we can not have field level  Update log records need not include the after images. locking. 15 16 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 4