Jun-Ki Min

Slide Purpose of Database Recovery ◦ To bring the database into the last consistent stat e, which existed prior to the failure. ◦ To preserve transaction properties (Atomicity, Co nsistency, Isolation and Durability).  Example: ◦ If the system crashes before a fund transfer trans action completes its execution, then either one or both accounts may have incorrect value. Thus, th e database must be restored to the state before t he transaction modified any of the accounts.

Slide Types of Failure ◦ The database may become unavailable for use due t o  Transaction failure: Transactions may fail because of i ncorrect input, deadlock, incorrect synchronization.  System failure: System may fail because of addressing error, application error, operating system fault, RAM fa ilure, etc.  Media failure: Disk head crash, power disruption, etc.

 Principle of Recovery: redundancy ◦ dump : archive ◦ log, journal) : store old/new value into additional file

DB 1 DB 2 Disk controller 1 2 Disk controller 2 Processor 1 Processor 2

 Type of storage 1) volatile storage ◦ Main memory ◦ Lost data when system failuer 2) nonvolatile storage) ◦ Disk or flash memory or tape ◦ No loss of data when system failure ◦ Loss data by storage failure 3) stable storage ◦ No loss of data ◦ Consist of several nonvolatile storage

 Block moving between Disk and main memory ◦ Input(B i )  Move disk block containing data B i to main memory  On demand ◦ Output(B j )  Move disk block containing B i to disk  Done by Buffer Manager Main memory DISK Block BiBi BjBj BiBi BjBj Input(B i ) Output(B j )

 Data moving program and DB X : Name of data item x : local variable ◦ Read(X) : assign data item X to local variable x  If data item X is not is main memory, do Input(B x ) where block B x containing X ◦ Write(X) : assign local variable x’s value to data item X  If data item X is not is main memory, do Input(B x ) where block B x containing X  Store B x to DISK is done by buffer manager

 force-output of B x ◦ Do Output(B x ) ◦ When no available space in main memory  Read(X) ◦ A transaction access X ◦ Internally, do Input(B x ) if required.  Write(X) ◦ A transaction updates X. And then reflect the change to DB ◦ Generally, Output(B x ) for Write(X) is not done immediately. ◦ If system is failure when Output(B x ) is not doen although Write(X) is done → lost of updated X

 Sequence of operators ◦ T : S i → S j, S i, S j ∈ S ◦ S : a set of consistent stage of DB  Logical unit of a job  Feature of Transaction(ACID) ◦ Atomicity  All or Nothing ◦ Consistency  After transaction, keep consistency ◦ Isolation  Intermediate result of a transaction is not accessed by other transactions ◦ Durability  The result of successes transaction is reflected to DB Begin_Trans … End_Trans

▶Transaction Recovery ◦ transaction: logical unit for recovery ▶Operator for atomicity ◦ Commit  Success execution ◦ Rollback  Failure of execution  Inconsistent state  UNDO

 Update ◦ update in place ◦ Indirect Update block i buffer Input Output disk Main memory block i buffer Input Output block j disk Main memory

▶Transaction state active Partial commit failed commit begin error Hardware error Disk outputroll back -commit-Restart/abort roll back

 Example of Transaction ◦ Transfer 100 from account A to account B BEGIN_TRANS; UPDATE ACCOUNT SET Balance = Balance WHERE Accnt = 'A'; IF ERROR GO TO UNDO; UPDATE ACCOUNT SET Balance = Balance WHERE Accnt = 'B'; IF ERROR GO TO UNDO; COMMIT TRANS; GO TO FINISH; UNDO: ROLLBACK TRANS; FINISH: RETURN; END_TRANS

 Log Record ◦ : transaction T i begin ◦ : T i update data item X j ’s value V 1 to V 2 ◦ : T i finish

 Until partial commit, all Outputs are deferred ◦ Changes are stored in log ◦ After in log, update DB  commit  means partial commit ◦ No UNDO ◦ Log record : prepare REDO

 Failure after ◦ REDO(T i ) :  Failure before ◦ Ignore log, restart T i log time DB A=1000 B=2000 T 0 : Read (A) A := A-100 Write (A) Read (B) B := B+100 Write (B) A=900 B=2100

 Feature of REDO ◦ Idempotent : several REDOs is equal to a REDO REDO( REDO( … ( REDO(X) ) )… ) = REDO(X)

 Log record (UNDO) ◦ Failure before UNDO(T i ) : with previous value Failure after REDO(T i ) : with after value log time DB A=1000, B=2000 T 0 : Read (A) A := A-100 Write (A) A=900dirty data Read (B) B := B+100 Write (B) B=2100

 Feature of UNDO ◦ Idempotent ◦ UNDO( UNDO( … ( UNDO(X) ) ) … ) = UNDO(X)

 When system failure, log based methods ◦ Check whole log for Redo and Undo→too much time ◦ Unnecessary Redo   checkpointing

Checkpointing ◦ Time to time (randomly or under some criteria) the database flushes its buffer to database disk to minimize the task of recovery. The following steps defines a checkpoint operation: 1.Suspend execution of transactions temporarily. 2.Force write modified buffer data to disk. 3.Write a [checkpoint] record to the log, save the log to disk. 4.Resume normal transaction execution. ◦ During recovery redo or undo is required to transactions appearing after [checkpoint] record.

 Transaction ◦ T 2, T 4 : REDO ◦ T 3, T 5 : UNDO ◦ T 1 : independant T 1 | | T2T2 | | T3T3 | | T 4 | | T 5 | | time c(check point)f(failure time)

 Making transaction list ◦ Make two empty list: Undo-list Redo-list ◦ Insert transactions that are activated at checkpoint time to Undo-list ◦ Forward log  when meet, insert T i to Undo- list ◦ Forward long  when meet, remove T i from Undo-list and insert it to Redo-list

 Perform Undo/Redo ◦ For all transactions in Undo-list, perform Undo in inverse order ◦ And then, for all transactions in Redo-list, perform Redo in the order  backward recovery ◦ Do Undo  forward recovery ◦ Do Redo  Until finish recovery, new transaction cannot begin

 Two page tables ◦ Current page table ◦ Shadow page table  In transaction, current page table is used

 Page 2 is written i i Shadow page table Disk Page current page table

 Advantages ◦ No overhead to write log record → reduce # of disk access ◦ Undo is simple, and no Redo → fast recovery from failure  Drawbacks ◦ commit overhead ◦ data fragmentation ◦ garbage collection ◦ Hard to support to concurrent transaction

 WAL ◦ When in-place update (immediate or deferred) is used then log is necessary for recovery and it must be available to recovery manager. This is achieved by Write-Ahead Logging (WAL) protocol. WAL states that  For Undo: Before a data item’s AFIM is flushed to the database disk (overwriting the BFIM) its BFIM must be written to the log and the log must be saved on a stable store (log disk).  For Redo: Before a transaction executes its commit operation, all its AFIMs must be written to the log and the log must be saved on a stable store. BFIM - BeFore Image AFIM – AFter Image

 Database buffering ◦ When block B 2 is loaded, B 1 is selected as a victim and B 1 is dirty 1.All log records related to B1 are stored to disk 2.store B 1 to disk 3.B 2 is loaded   but, OS does not support write-ahead logging

 alternative 1 ◦ DBMS maintains a part of main memory ◦ DBMS maintains movement of blocks ◦ Cons  restricted size of memory for DB  Waste memory

 alternatives 2 ◦ Use virtual memory as a buffer for DBMS ◦ Shift between DB and virtual memory is under DBMS  Store log before changed block ◦ cons  Additional disk I/O  To store block B, two outputs (done by OS and DBMS) and one input

 A transaction access several databases  Atomicity ◦ 2-phase commit Global recovery manager (coordinator) protocol Local recovery manager

 phase 1 ◦ Coordinator sends message ‘prepare for commit’ to all participations ◦ Each participation force out all records and replies OK. If not possible, replies ‘NOT OK’  phase 2 ◦ If coordinator gets OK from all participations, coordinator records ‘commit’ and send commit message.  All participations record ‘commit’ ◦ Otherwise coordinator records ‘rollback’ and sends ‘rollback’ message. All participations do roll back.