Intro to Recovery
Haerder & Reuter
Recall that Recovery guarantees Atomicity and Durability.
Paper outlines issues and options for recovery.
Types of Failure
- Transaction failure
- System failure
- Media failure
- ATOMIC: a transactions updates become visible on disk all at once. System Rs
"shadow paging" scheme did this. Pros/cons?
- NOT ATOMIC: parts of transactions can be on disk without other parts. Pros/cons?
Buffer Pool Eviction Options
- STEAL: a transactions updates may be flushed from the buffer at arbitrary times,
since another transaction is allowed to "steal" a buffer pool frame. Pros/cons?
- NO STEAL: all of a transactions updates remain in the buffer pool until commit
- FORCE: at commit time, all modified pages are forced (flushed) to disk. Pros/cons?
- NO FORCE: modified pages may remain in the buffer pool even after commit. Pros/cons?
- Depending on the option chosen above, need some of REDO and UNDO log records to support
- Log records can be logical (e.g. "inserted a tuple t into relation R), or physical
(e.g. "byte 74 of page 255 used to be r and now is s").
Pros/cons of each?
- Physical log records can be before/after images of pages (subpages), or diffs.
- In order to speed up recovery, its nice to have "checkpoint" records
that limit the amout of log that needs to be processed during recovery. It can be tricky
to do efficient checkpoints.
State of the Art (as exemplified by ARIES)
- Focus on speed and generality, rather than simplicity.
- NOT ATOMIC, STEAL, NO FORCE. This allows the buffer manager to make intelligent (i.e.
efficient) decisions about when and what to flush to disk.
- Log data is "physiological" i.e. some is physical (e.g. B-tree page
splits), and some is logical (heap-tuple insertions.)
Many more details in ARIES paper!