Failure Recovery
DBMS responsible for recovery management
- Regarding atomicity: enable a transaction to be
- Committed (With a guarantee database changes are permanent)
- Aborted (with a guarantee that there are no database changes)
- Regarding reliability: Enable a database to be recovered to a consistent state in case of hardware or software failure
Interaction with recovery management
- Input: 2PL and ACA schedule of operations produced by the transaction manager
- Output: Schedule of object rads, object writes, and object forced writes
Approaches to Recovery
- Shadowing
- Copy-on-write and merge-on-commit approaches
- Poor clustering
- Used in system
but not in modern systems - Logging
- Uses log files on separate stable media
- Good utilization of buffers
- Preserves original clusters