File Processing : Recovery 2005, Spring Pusan National University Ki-Joune Li

Failure Classification Transaction failure : Logical errors: internal error condition System errors: system error condition (e.g., deadlock) System crash: a power failure or other hardware or software failure Fail-stop assumption: non-volatile storage contents are assumed to not be corrupted by system crash Database systems have numerous integrity checks to prevent corruption of disk data Disk failure

Recovery Algorithms Recovery algorithms : should ensure database consistency transaction atomicity and durability despite failures Recovery algorithms have two parts Preparing Information for Recovery : During normal transaction Actions taken after a failure to recover the database

Storage Structure Volatile storage: Nonvolatile storage: does not survive system crashes examples: main memory, cache memory Nonvolatile storage: survives system crashes examples: disk, tape, flash memory, non-volatile (battery backed up) RAM Stable storage: a mythical form of storage that survives all failures approximated by maintaining multiple copies on distinct nonvolatile media

Recovery and Atomicity Modifying the database must be committed Otherwise it may leave the database in an inconsistent state. Example Consider transaction Ti that transfers $50 from account A to account B; goal is either to perform all database modifications made by Ti or none at all. Several output operations may be required for Ti For example : output(A) and output(B). A failure may occur after one of these modifications have been made but before all of them are made.

Recovery and Atomicity (Cont.) 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

Log-Based Recovery A log : must be kept on stable storage. <Ti, Start>, and <Ti, Start> < Ti, X, V1, V2 > Logging Method When transaction Ti starts, <Ti start> log record When Ti finishes, <Ti commit> log record Before Ti executes write(X), <Ti, X, Vold , Vnew > log record We assume for now that log records are written directly to stable storage Two approaches using logs Deferred database modification Immediate database modification

Deferred Database Modification The deferred database modification scheme records all modifications to the log, writes them after commit. Log Scheme Transaction starts by writing <Ti start> record to log. write(X) : <Ti, X, V> Note: old value is not needed for this scheme The write is not performed on X at this time, but is deferred. When Ti commits, <Ti commit> is written to the log Finally, executes the previously deferred writes.

Deferred Database Modification (Cont.) Recovering Method During recovery after a crash, a transaction needs to be redone if and only if both <Ti start> and<Ti commit> are there in the log. Redoing a transaction Ti ( redoTi) sets the value of all data items updated by the transaction to the new values. Deletes Ti such that <Ti ,start> exists but <Ti commit> does not.

Deferred Database Modification : Example If log on stable storage at time of crash is as in case: (a) No redo actions need to be taken (b) redo(T0) must be performed since <T0 commit> is present (c) redo(T0) must be performed followed by redo(T1) since <T0 commit> and <Ti commit> are present T0: read (A) T1 : read (C) A: = A - 50 C:= C- 100 write (A) write (C) read (B) B:= B + 50 write (B)

Immediate Database Modification Immediate database modification scheme Database updates of an uncommitted transaction For undoing : both old value and new value Recovery procedure has two operations undo(Ti) : restores the value of all data items updated by Ti redo(Ti) : sets the value of all data items updated by Ti When recovering after failure: Undo if the log <Ti start>, but not <Ti commit>. Redo if the log both the record <Ti start> and <Ti commit>.

Immediate Database Modification : Example Recovery actions in each case above are: (a) undo (T0): B is restored to 2000 and A to 1000. (b) undo (T1) and redo (T0): C is restored to 700, and then A and B are set to 950 and 2050 respectively. (c) redo (T0) and redo (T1): A and B are set to 950 and 2050 respectively. Then C is set to 600

Idempotent Operation Result (Op(x)) = Result (Op(Op(x)) Example Increment(x); : Not Idempotent x=a; write(x); : Idempotent Operations in Log Record Must be Idempotent, otherwise Multple Executions (for redo) may cause incorrect results

Checkpoints Problems in recovery procedure by Log record scheme : searching the entire log records : time-consuming Discard unnecessary redo transactions already executed. Checkpoint Method Marking Checkpoint Recovery from Checkpoint Output all log records currently residing in main memory onto stable storage. Output all modified buffer blocks to the disk. Write a log record < checkpoint> onto stable storage.

Checkpoints (Cont.) In case of failure Tc Tf T1 T2 T3 T1 can be ignored T2 and T3 redone. T4 undone Tc Tf T1 T2 T3 T4 checkpoint system failure

Shadow Paging Mechanism maintain two page tables shadow page table the current page table, and the shadow page table shadow page table state of the database before transaction execution Shadow page table is never modified during execution To start with, both the page tables are identical. Whenever any page is about to be written for the first time A copy of this page is made onto an unused page. The current page table is then made to point to the copy The update is performed on the copy

Shadow Page : Example Old State New State