1. DURABILITY OF TRANSACTIONS AND CRASH RECOVERY

2. ACID Properties of transactions
Atomicity
Consistency
Isolation
Durability

3. System Crashes System failure due to:
Problem in the processor
Problem in the memory due to a bug
Power loss -> loss of memory (since it is volatile)
In case of system failure, the recovery procedure is executed to restore the database in a consistent state.

4. Motivation Atomicity: Durability: Transactions may abort (“Rollback”).
What if DBMS stops running? (Causes?)
Desired Behavior after system restarts:
T1, T2 & T3 should be durable.
T4 & T5 should be aborted (effects not seen).
crash! T1 T2 T3 T4 T5

5. Assumptions Concurrency control is in effect.
Strict 2PL, in particular.
Updates are happening “in place”.
i.e. data is overwritten or deleted from the disk.
Memory and disk are organized into pages
Page R/W from/to disk is an atomic operation

6. Main Memory (divided into blocks called pages) volatile
Hard Disk – non voiatile
Write
Read
Unit of transfer is
A page for efficiency
reasons!

7. Handling the Buffer Pool
Force every write to disk at the end of the transaction?
Poor response time.
But provides durability.
Steal buffer-pool frames from uncommited transactions?
buffer manager allows an update made by an uncommitted transaction to overwrite the most recent committed value of a data item
If not, poor throughput.
If so, how can we ensure atomicity?
Possible rollbacks
No Steal
Steal
Force
Trivial
Desired
No Force

8. More on Steal and Force STEAL (why enforcing Atomicity is hard)
What if the transaction that steals (overwrite) aborts?
Must remember the old value at steal time
a NO-STEAL policy guarantees that the data values on non-volatile storage are valid, so they do not need to be restored
NO FORCE (why enforcing Durability is hard)
What if system crashes before a modified page is written to disk?
Write as little as possible, in a convenient place, at commit time, to support REDOing modifications.

9. Basic Idea: Logging
Record REDO and UNDO information, for every update, in a log.
Sequential writes to log (put it on a separate disk).
Minimal info (diff) written to log, so multiple updates fit in a single log page.
Log: An ordered list of REDO/UNDO actions
Log record contains:
<TID, pageID, offset, length, old data, new data>
and additional control info.

10. Database
Nonvolatile
memory
Log
cache
volatile
memory
Log buffer

11. Write-Ahead Logging (WAL)
The Write-Ahead Logging Protocol:
Must force the log record for an update before the corresponding data page gets to disk. (Question: what happens if we do the update first and then append to the log?)
Must write all log records for a transact before commit.
#1 guarantees Atomicity.
#2 guarantees Durability.
Exactly how is logging (and recovery!) done?
We’ll study the ARIES algorithms.

12. Some Notation LSN: Log Sequence Number Page LSN: stored in page
logical address of record in the log
Page LSN: stored in page
LSN of most recent update to that page
PrevLSN: stored in log record
identifies previous log record for that transaction
Flush: if the slot in cache is not dirty, do nothing; otherwise, copy the value into stable storage
Use dirty bit for deciding flushing operation

13. WAL & the Log Each log record has a unique Log Sequence Number (LSN).
LSNs always increasing.
Each data page contains a pageLSN.
The LSN of the most recent log record for an update to that page.
System keeps track of flushedLSN.
The max LSN flushed so far.
WAL: Before a page is written,
pageLSN £ flushedLSN
Log records
flushed to disk
pageLSN
“Log tail”
in RAM

14. Compansation Log Records
CLRs: undo only log records
For recording actions performed during rollback
one CLR for each normal log record which is undone

15. Log Records Possible log record types: Update LogRecord fields: Commit
Abort
End (signifies end of commit or abort)
Compensation Log Records (CLRs)
for UNDO actions
LogRecord fields:
prevLSN (log num)
TID
type
length
pageID
offset
before-image
after-image
update
records
only

16. Normal Execution of a Transaction
Series of reads & writes, followed by commit or abort.
Strict 2PL.
STEAL, NO-FORCE buffer management, with Write-Ahead Logging.

17. Checkpointing
Periodically, the DBMS creates a checkpoint, in order to minimize the time taken to recover in the event of a system crash. Write to log:
begin_checkpoint record: Indicates when chkpt began.
end_checkpoint record: Contains current transact table and dirty page table.
Just stores all the information at that time in a safe place
Takes a snapshot

18. Recovery Phases (ARIES)
Analysis pass
Forward from last check point
Redo pass
Forward from RedoLSN, which is determined in analysis pass
Undo pass
Backwards from end of log, undoing incomplete transactions

19. Crash Recovery: Big Picture
Oldest log rec. of trsct active at crash
Start from a checkpoint (found via master record).
Three phases. Need to:
Figure out which transacts committed since checkpoint, which failed (Analysis).
REDO all actions.
(repeat history)
UNDO effects of failed transacts.
Smallest recLSN in dirty page table after Analysis
Last chkpt
CRASH A R U

20. Recovery: The Analysis Phase
Reconstruct state at checkpoint.
via end_checkpoint record.
Scan log forward from checkpoint.
Find transactions to be rolled back
Find LSN of last record written by each such transaction

21. Recovery: The REDO Phase
We repeat History to reconstruct state at crash:
Reapply all updates (even of aborted transacts!)
Scan forward from RedoLSN
For all transactions, even those to be undone

22. Recovery: The UNDO Phase
Single scan backwards in log
Undo actions that needs to be unrolled
Learned in analysis
for each transaction, when a log record is found, use prev_LSN fields to find next record to be undone
Keep CLR logging

23. Summary of Logging/Recovery
Recovery Manager guarantees Atomicity & Durability.
Use WAL to allow STEAL/NO-FORCE w/o sacrificing correctness.
LSNs identify log records; linked into backwards chains per transaction (via prevLSN).
pageLSN allows comparison of data page and log records.

24. Summary, Cont.
Checkpointing: A quick way to limit the amount of log to scan on recovery.
Recovery works in 3 phases:
Analysis: Forward from checkpoint.
Redo: Forward from oldest recLSN.
Undo: Backward from end to first LSN of oldest transact alive at crash.
Upon Undo, write CLRs.
Redo “repeats history”: Simplifies the logic!