1. Jun-Ki Min

2. Slide 19- 2 1 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.

3. Slide 19- 3 2 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.

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

5. DB 1 DB 2 Disk controller 1 2 Disk controller 2 Processor 1 Processor 2

6.  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

7.  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 )

8.  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

9.  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

10.  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

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

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

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

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

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

16.  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

17.  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

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

19.  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

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

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

22. 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.

23.  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)

24.  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

25.  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

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

27.  Page 2 is written i i Shadow page table Disk Page current page table 1 2 3 4 5 6767 8 9 10 1 2 3 4 5 6767 8 9

28.  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

29.  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

30.  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

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

32.  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

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

34.  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.