Transactional Recovery andCheckpoints
Chap. 10.6-10.8
Recovery is needed
•Reading - involves buffers, paging and LRUreplacement (operating system)
•Writing - when to write updates to disk?  WhenLRU replaces (use dirty bit)?  
•no immediate durability  
•no atomicity
•But what if crash and still in memory?
•Have a log buffer with log entries and a log file
Log Buffer and Files
•Write log entry from log buffer, writechanges to disk (log file) at intervals
•log file used to perform recovery
•log buffer and log file guarantees atomicityand durability
How?
•log entries: 
W, T#, data_item, before_value, after_value
or RID, list of cols with before and after values
•also insert and delete tuple log entries
• why before values?
– in case must UNDO
• why after values?
– in case must REDO
When done?
•Log buffer written to log file, when a Tcommits or log buffer is full
•2 concepts: 
–entries (updates) to log file
vs.
–making changes to data on disk
Actions
•For atomicity 1)  Rollback - make list of committed T'sand UNDO uncommitted T's actions
• For durability 2)  Rollforward - to REDO committed T'sactions
Log Entries
•In log entry keep track of: 1)  committed T's ( C, T#) 2)  uncommitted T's - enter writes but notreads 3)  Start of Transactions (S, T#)
Example
R1(A,50)W1(A,20)R2(C,100)W2(C,50)C2R1(B,50)W1(B,8)C1
1             2               3              4            5    6            7           8
        Log entries:            1.  (S1)            2. (W,1,A,50,20)            3. (S2)            4. (W,2,C,100,50)            5. (C2)            6.  no entry            7.  (W,1,B,50,80)            8. (C1)
            What if crash on operation 7?
How to recover
Rollback until log file empty 1.  C2 - T2 on committed list 2.  (W,2,C,100,50)  C2 on list, do nothing 3.  (S,2)  T2 no longer active 4.  (W,1,A,50,20) UNDO this update, T1not on the committed list 5.  (S1)  T1 no longer active
How to recover cont’d
Rollforward 6.  S1 - no action 7.  (W,1,A,50,20) T1 uncommitted - noaction 8.  (S,2) no action 9.  (W,2,C,100,50) Redo update10.  (C,2) no action
   11. done
Durability
•When write log buffer to log file - read afterwrite protocol in performing disk writesguarantees commit fails if error in diskwrite.
•When successful write, durability (write to2 different disks for extra durabilityguarantee)
Problems
•Potential problems with log files 1) durability - commits successful onlyonce log file written on disk  2)  atomicity - Be sure dirty pages of datanot written to disk before log entry   (iffailure and log entry not written?) else willnever UNDO or REDO if have to
Solutions
Can modify LRU replacement to ensure data notwritten to disk before log file
1. updated data page not written to disk untilcommit - no UNDO processing ever,  no beforeimages needed in logs but what if lot ofupdates?  can't keep all in memory
2. write ahead log guarantee (WAL) logsequence number - every log entry keeps trackof smallest LSN written to log file since lastwrite,  keep track of updates to data pages(pgmax) cannot write page to disk unless pgmax < LSN
Recovery
•Recovery Checkpoints   used so only have to rollback to a certainpoint
•T's short-lived (take a few seconds)therefore rollback is quick - only a few T'sactive that need to be UNDONE
• rollforward takes longer - many T's toREDO, keep track of start T's, etc.
•3 approaches for checkpoints
Commit consistent
1.  Commit consistent -needed when count of logevents exceeds some limit     Enter checkpoint state:
 a)  no new T's start until checkpoint complete
 b)  DB processing continues until all existing T'scommit and log entries on disk
 c)  current log buffer written to log file, all dirty pageswritten to disk
 d)  when a)-c) complete, special log entry CKPTentered    ( these steps are the same as an orderly shutdownof the system )
Commit consistent cont’d
•To recover:  Rollback until CKPT, then REDOcommitted since CKPT
•Problems 
– But what if some transactions are long-lived?
– must wait a long-time for them to finish, withno new T's active
Cache-consistent
2.  Cache-consistent checkpoint - aim toreduce time if long transactions
 a)  No new T's permitted to start
 b)  existing T's cannot start any new ops
 c)  current log buffer written to disk, all dirtydata pages to disk
 d)  log entry (CKPT, list of active T's) written onlog file on disk
Cache-consistent cont’d
•To recover:
– must rollback past checkpoint
–rollback the same as for commit consistent,then keep rolling back until list in CKPT allundone (if not committed yet)
– Rollback - given the list of active T's, removethose committed then left with a list of T's toUNDO
– Rollforward - REDO all updates by committedT's start at first op after last CKPT
Cache-consistent cont’d
•Problems:   Time to flush dirty pages to disk
 R1(A,10)W1(A)C1R2(A,1)R3(B,2)W2(A,3)R4(C,5)CKPTW3(B,4)C3R4(B,4)W4(C,6)C4 crash
Fuzzy
 3.  Fuzzy checkpoint
aim to reduce time to perform a checkpoint (CKPTn+1)
 makes use of 2 checkpoint events;  CKPTn-1 and CKPTn
 a)  Prior to checkpoint, remaining pages dirty since
 b)  no new T's starts - existing T's no new ops
 c)  current log buffer written to disk with (CKPTn, list)
 d)  set of pages in buffer that are dirty since CKPTn-t isnoted background process makes sure pageschanges out on disk by next checkpoint
Fuzzy
•Rollforward starts with first log entryfollowing 2nd to last checkpoint log       CKPTn-1 ......  CKPTn     (start atCKPTn-1)
•set of dirty pages since CKPTn-1 willhopefully be written to disk by CKPTn+1
• avoid buffer flushing at time of CKPTn