1 / 6

Motivation for Recovery

This document covers essential concepts in database transaction management, focusing on atomicity, durability, and the recovery process in the event of system failures. It discusses transaction aborts (rollback), the importance of log-based recovery (Write-Ahead Logging Protocol), and methods to enhance performance while maintaining data integrity. You'll learn about the role of log sequence numbers (LSNs), the three-step recovery process, and techniques like 'No Steal,' 'Steal,' and 'Force' for managing the buffer pool effectively. Get insights into guaranteeing that transactions are atomic and durable even during concurrent access and crashes.

kolya
Télécharger la présentation

Motivation for Recovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Handling the Buffer Pool • Force every write to disk? • Poor response time. • But provides durability. • Steal buffer-pool frames from uncommitted transactions? • If not, poor throughput. • If so, how can we ensure atomicity? No Steal Steal Force Trivial Desired No Force

  3. 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 (difference) written to log, so multiple updates fit in a single log page. • Log: An ordered list of REDO/UNDO actions • Log record contains: <XID, pageID, offset, length, old data, new data> • and additional control information. • The Write-Ahead Logging Protocol: • Must force the log record for an update before the corresponding data page gets to disk. • Must write all log records for a transaction beforecommit.

  4. DB RAM LSNs pageLSNs flushedLSN pageLSN WAL & the Log • Each log record has a unique Log Sequence Number (LSN). • LSNs always increasing. • Each data pagecontains 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 “Log tail” in RAM

  5. Recovery • Three steps: (a la` ARIES) • Starting from a checkpoint: • Analysis: figure out which transactions committed • since the checkpoint, and which failed. • REDOall actions in the log. • UNDO effects of failed transactions.

  6. Summary • Users access the database concurrently, and sometimes there are • crashes. • Transactions are sets of operations that are guaranteed to be atomic. • The DBMS guarantees: Atomicity, Consistency, Isolation, • Durability. • Isolation and consistency are guaranteed via locking: 2-phase • (need special care for deadlocks). • Atomicity and durability are guaranteed by: • Logging • Recovery manager (that uses the log). There are MANY MANY more missing details!

More Related