Recovery: An Intro to ARIES Based on SKS 17. Instructor: Randal Burns Lecture for April 1, 2002 Computer Science Johns Hopkins University

Transcription

1 Recovery: An Intro to ARIES Based on SKS 17 Instructor: Randal Burns Lecture for April 1, 2002 Computer Science Johns Hopkins University

2 Log-based recovery Undo logging Redo logging Restart recovery Checkpoints Overview

3 Goals Provide high-availability (fast repair) and consistency in the presence of failures Transaction failures logical error: internal condition, bad input, data not found, resource problems, etc. Correspond to software faults. system error: deadlock or other system problem that prevents this execution of a transaction rollback: explicit call to fail this transaction by application System crash bug in OS or DB hardware problems environmental reasons: power implement the failstop property

4 The Database Log What s a log? A sequential file that contains a record of actions taken by an entity Entity is the DBMS, actions are data writes What s a log look like?a contiguous region of storage, preferably a whole disk Why contiguous? So that sequential log writes are written sequentially to storage. Writing sequentially on storage is very important, as opposed to seeking Why a whole disk? The storage is not important. The arm is the valuable resource. So that no other workload shares the disk (arm) resource and interferes with sequential writing.

5 What does the log contain? Log records (Duh!): an update record describes a single database writes and consists of: Transaction ID Data-item identifier (typically physical, disk location, rather than logical, tuple) Old value New value < TID, Disk Block, Old, New > This is a very general form (we will look at more specific forms later) that allows operations to be done and undone There are other types of entries Transaction begin and end, checkpoints, rollbacks

6 The Logging Principle Logically, the log only grows, nothing is ever deleted If you want to undo some update < TID, Block, Old, New > place an equivalent undo in the log < TID(rollback), Block, New, Old > How do we implement a log in a fixed amount of space? Transactions that are resolved (aborted or committed) can be written to the main database, shrinking the log from its head. We never delete from the tail and we remove records for unresolved transactions Problem: long running transactions can overflow the log Yup you bet. Recover from this in a failfast manner.

7 What s What The log: non-volatile storage Writes to the log are I/O The DB: non-volatile storage Writes the the DB are I/O In-memory pages of the DB Updates (not writes) are made to an in-memory copy of blocks of the DB. Pages and blocks are the same-ish thing. Pages in memory, blocks on disk. 1-to-1 correspondence.

8 Deferred Modification (Redo) The log contains update entries that allow operations to be redone <TID, Block, New> Updates are written only to the log By written, we mean I/O to the DB image. The updates are applied to an in-memory copy of the database page Once a transaction commits, i.e. it has written a commit record in the log, all of the updates are applied to the database We note that the log is not the database. The log is a set of operations that transform the database

9 Redo Example

10 Immediate Modification (Undo) The log contains update entries that allow operations to be undone <TID, Block, Old> Updates are written (I/O) into the database and log

11 Undo Example

12 Steal and Force Steal, the ability to write an uncomitted update to disk This is called stealing a page Frees up system resources Requires undo logging Force, the requirement that all pages dirtied by a transaction are on disk when a transaction commits No force requires redo logging Steal, No-force combines high-performance with memory management Again this is ARIES.

13 Restart Recovery No volatile information, just a database and log. No idea what transactions were active. General form of recovery Analysis, take a forward pass over the log constructing lists of committed and aborted/active transaction transactions active when a failure occurred are aborted during restart recovery Redo, forwards pass to apply any committed updates in log that are not in the DB Undo, backwards pass over the log to undo un-committed operations that are currently in the DB

14 Redo Recovery Forward pass over the log to redo the operations of committed transactions that are not in the database With analysis Analysis pass to resolve outcomes of transactions Forward pass to perform updates again Without analysis Forward pass to perform updates to in-memory pages Write pages to DB when a commit record is found Discard pages for transactions that rollback or are incomplete Tradeoff between memory usage (possible to run out of memory without analysis) and 2 passes Don t want to write undo records for redo operations so you cannot steal pages

15 Undo Recovery Backward pass over the log to undo the operations of uncommitted transactions that are not in the database Requires no separate analysis pass. In a backward pass if the recovery manager sees a TID for which no commit record was already read, the operation needs to be undone.

16 Undo and Redo Compared Redo Advantages: fast updates write to log only Disadvantages: slower restart (not significant), can run out of memory when the system has many uncommitted updates. Undo Advantages: never runs out of system memory, easy and efficient recovery Disadvantages: requires synchronous writes for every update to both log and DB. Note that writing the DB is much less efficient than writing the log, because the log is sequential The real solution: Undo/Redo logging, that s ARIES

17 Undo and Redo Together Undo/redo log records: can do either action So it is possible that Uncommitted updates are written to the DB Committed updates are not written to the DB Restart recovery Analysis: determine winner and loser transactions Redo: bring memory into state consistent with state of memory at crash time Undo: undo actions of loser transactions that abort Redo work must be complete before undo work

18 Checkpoints The problem: logs grow to be really quite large. They can run out of space and take a long time to pass over during restart. The solution: write all committed updates (pages) to disk and write a log record that indicates all of the transactions that are active at the current time. This is called a checkpoint and reduces the amount of work that needs to be done on restart.

19 Recovery with Checkpoints Analysis: backward pass to the most recent checkpoint Construct undo-list and redo-list Add active transactions on the checkpoint that are not on the redo-list to the undo-list Undo: backward pass until the start records for all transactions on the undo-list have been found Redo: forward pass from the most recent checkpoint The undo past likely went past the last checkpoint