lec25 - 1 4/10/11 EECS 484: Database Management Systems,...

Info iconThis preview shows pages 1–5. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 1 4/10/11 EECS 484: Database Management Systems, Kristen LeFevre 1 Logging and Recovery Chapter 16.7, 18 4/10/11 EECS 484: Database Management Systems, Kristen LeFevre 2 Logging and Recovery The world isnt perfect Systems crash Devices (and even entire data centers!) fail Transactions abort Need to design DBMS to be resilient to these problems! Three main challenges: Aborted Transactions System Crashes: Lose the contents of RAM Media Failures: Lose data stored on one or more secondary devices (e.g., disks or tapes) 2 4/10/11 EECS 484: Database Management Systems, Kristen LeFevre 3 Maintaining ACID on Failure Atomicity Transactions may abort; need to undo actions Durability Committed Xacts should persist Desired Behavior after system restarts: T1 & T2 should be durable. T3, T4 & T5 should disappear entirely T1 T2 T3 T4 T5 crash A B C B C B B B 4/10/11 EECS 484: Database Management Systems, Kristen LeFevre 4 Agenda Focus on recovering from system crashes Lose the contents of RAM (buffer pool) Need to completely undo the effects of all incomplete transactions Make sure committed transactions persist What makes this hard? Steal / No-Force Buffer Management Policy ARIES Recovery Protocol Breakthrough in modern systems 3 4/10/11 EECS 484: Database Management Systems, Kristen LeFevre 5 Buffer Manager & Transactions Can changes made to object O by transaction T be written to disk before T commits? If yes, called a steal approach When transaction T commits, do we need to assume all changes immediately forced to disk? If yes, called a force approach 4/10/11 EECS 484: Database Management Systems, Kristen LeFevre 6 Buffer Manager & Transactions No Force Problem: Crash before a page is flushed to disk Force Poor performance Force Steal Yes No No Yes Steal Problem: Page being stolen (and flushed) was modified by an uncommitted transaction No Steal Poor performance Desired Trivial Challenge: How to provide atomicity and durability in a steal, no force environment? 4 4/10/11 EECS 484: Database Management Systems, Kristen LeFevre 7 Basic Solution Idea: Logging Every time a change is made, record information in an append-only log . Log stored in stable storage to survive system crash Update log records describe changes that were made, and how to UNDO / REDO them E.g., before/after images Each log record contains log sequence number (LSN) prevLSN, XID Log records for a transaction are chained by prevLSN 4/10/11 EECS 484: Database Management Systems, Kristen LeFevre 8 Write-Ahead Logging (WAL) The Write-Ahead Logging Protocol: 1. Must force the log record for an update before the corresponding data page gets to disk.gets to disk....
View Full Document

This note was uploaded on 12/08/2011 for the course EECS 484 taught by Professor Staff during the Winter '08 term at University of Michigan.

Page1 / 14

lec25 - 1 4/10/11 EECS 484: Database Management Systems,...

This preview shows document pages 1 - 5. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online