Recovery Methods 5DV120 — Database System Principles Ume˚ a University Department of Computing Science Stephen J. Hegner hegner@cs.umu.se http://www.cs.umu.se/~hegner Recovery Methods 20160814 Slide 1 of 42
The Issue of Recovery in the DBMS Context • In the domain of operating systems, the focus with recovery is to restore the system to a working state as quickly as possible. • Restoring applications and storage to the states they were in when the failure occurred is not a priority, and is considered the responsibility of the application itself. • In the domain of database systems, the emphasis is very different. • The integrity of both the database and of the transactions is of the highest priority. • For any type of failure, it must always be possible to: • Restore the system to a consistent state. • Know exactly which actions were committed to the database and which were aborted. Recovery Methods 20160814 Slide 2 of 42
Types of Database Storage • In addressing recovery issues, it is critical to distinguish three types of storage. Nonvolatile storage: Storage whose contents remains intact in the event of a system crash. • Typically hard disk or SSD. • Generally secondary storage of the computer system. Volatile storage: Storage whose contents may be lost in the case of a system crash. • Typically dynamic RAM (DRAM). • Generally primary storage of the computer system. Stable storage: Storage whose contents are very well protected against loss. • Nonvolatile storage with extra protection. • Typically replicated and/or distributed (possibly physically) on hard disks and/or SSDs. Recovery Methods 20160814 Slide 3 of 42
Types of Failures in Database Systems Transaction failure: A transaction failure can occur in two ways. 1. The transaction itself cannot continue for internal reasons ( e.g. , aborted by user, necessary input not available, programming error). 2. The transaction must be aborted by the system for some reason ( e.g. , deadlock or SSI victim). • In either case, recovery uses logs written to nonvolatile and/or volatile storage. System failure: System failures are those in which volatile storage, but not in general nonvolatile storage, is lost. • Examples include software failures, hardware failures, and power failures. • Recovery generally uses logs written to nonvolatile and preferably stable storage. Medium failure: This is a failure of secondary storage. • Recovery typically uses alternate secondary storage (via stability) or tertiary storage ( e.g. , tape backup). • The focus in these slides will be upon transaction failures. Recovery Methods 20160814 Slide 4 of 42
The Recovery Manager • At the center of the recovery process is the recovery manager . • It handles three distinct types of input. Transaction reads and writes: The recovery manager has the responsibility: • to log all writes is a secure way; • to manage reads in such a way that the correct image of the database is accessed. Transaction terminators: The recovery manager must: • process aborts of transactions, since portions of other transactions may need to be undone (rollback) or redone ; • process commits of transactions, so it is known which writes are permanent and cannot be aborted. Recover commands: The recovery manager handles explicit recovery requests from the system. Recovery Methods 20160814 Slide 5 of 42
Types of Database Operations Operations on data objects: These operations are on the usual data objects ( i.e. , records). • May be privatized to a single transaction, via locks in SVCC and via private versions (and locks) in MVCC. Operations on the schema infrastructure: These operation are on the schema infrastructure) which is shared by all transactions. Indices: Even if a transaction holds private copies of data objects (in MVCC), it will not, in general, hold private copies of indices. System data structures: Space allocation information and the like. Primary integrity constraints: For practical reasons, these are maintained in real time. • In all cases, privatization would require possible only with expensive, performance-degrading operations to be performed at the commit times of the transactions. • To some degree, the operations of a transaction T must be visible to any concurrent transaction T ′ . Recovery Methods 20160814 Slide 6 of 42
Pure Update Strategies • To understand recovery management, it is best to start with two “pure” variants, even though most practical strategies involve a combination of these two and other “tricks” as well. Immediate update: All write operations of a transaction result in immediate updates to the global database, where they are visible to other transactions. • Generally, updates to the infrastructure are immediate. • Other updates may be immediate under SVCC. Deferred update: All write operations of a transaction are entered into a log, which is not visible to other transactions. • When the transaction commits, the updates in these log entries are entered into the global database, visible to other transactions. • The choice of strategy affects: • the type of action required for recovery, and • the information which is necessary for the transaction log to support recovery. • Each of these pure strategies will be next be discussed within SVCC. Recovery Methods 20160814 Slide 7 of 42
Examples of Pure Update Strategies T 1 =r 1 � x � w 1 � x � r 1 � y � w 1 � y � • Consider: T 2 =r 2 � y � w 2 � y � r 2 � z � w 2 � z � Immediate Update Deferred Update T 1 T 2 TmpLog DB T 1 T 2 TmpLog DB r 1 � x � x 0 y 0 z 0 r 1 � x � x 0 y 0 z 0 w 1 � x � x 0 x 1 y 0 z 0 w 1 � x � x 1 x 0 y 0 z 0 r 2 � y � x 0 x 1 y 0 z 0 r 2 � y � x 1 x 0 y 0 z 0 w 2 � y � x 0 y 0 x 1 y 2 z 0 w 2 � y � x 1 y 2 x 0 y 0 z 0 r 1 � y � [ y 2 ] x 0 y 0 x 1 y 2 z 0 r 1 � y � [ y 0 ] x 1 y 2 x 0 y 0 z 0 w 1 � y � x 0 y 0 y 2 x 1 y 1 z 0 w 1 � y � x 1 y 2 y 1 x 0 y 0 z 0 cmt 1 x 0 y 0 x 1 y 1 z 0 cmt 1 y 2 x 1 y 1 z 0 r 2 � z � x 0 y 0 x 1 y 1 z 0 r 2 � z � y 2 x 1 y 1 z 0 w 2 � z � x 0 y 0 z 0 x 1 y 1 z 2 w 2 � z � y 2 z 2 x 1 y 1 z 0 cmt 2 x 1 y 1 z 2 cmt 2 x 1 y 2 z 2 Data item subscripts: 0 ⇒ original data; 1 ⇒ written by T 1 ; 2 ⇒ written by T 2 . Recovery Methods 20160814 Slide 8 of 42
The Transaction Log • To support the recovery process, the recovery manager maintains an extensive transaction log . • The physical configuration of the log varies substantially amongst implementations. • From a logical point of view, each entry in the log file must contain the following information. • transaction identity • time stamp • specific information about the transaction Recovery Methods 20160814 Slide 9 of 42
Form of Entries in the Transaction Log • Entries in the transaction log might have the following format: • For simplicity, time stamps are not shown, but such a stamp is associated with each object. Begin( Transaction ) Indicates that Transaction has begun. Commit( Transaction ) Indicates that Transaction has committed. Abort( Transaction ) Indicates that Transaction has aborted. Before Image( Transaction,Data Object ) The value of Data Object before it was written by Transaction . After Image( Transaction,Data Object ) The value of Data Object after it was written by Transaction . Read( Transaction,Data Object ) Indicates that Transaction performed a read on Data Object . Write( Transaction,Data Object ) Indicates that Transaction performed a write on Data Object . Recovery Methods 20160814 Slide 10 of 42
Operations in Support of Recovery • To understand the need for the various types of log entries, it is helpful to understand the various kinds of operations which may be performed in a recovery process. Re-do: In a re-do operation, the effect of a transaction is applied to the global database by applying its write operations which are found in the log. • Usually invoked if the transaction has committed, but the database had to be restored to an earlier state. Re-run: In a re-run operation, a transaction (typically which did not complete for some reason) is re-executed completely, without relying on log entries. • Usually invoked if the transaction terminated without committing. Rollback: In a rollback (or un-do ) operation, the operations which a transaction applied to the global database are reversed, with the old values restored. • Usually invoked before re-run if the transaction terminated without committing, but made immediate operations to the global database. Recovery Methods 20160814 Slide 11 of 42
Recommend
More recommend
