The Recovery Manager of the System R Database Manager

Abstract

The recovery subsystem of an experimental data management system is described and evaluated. The transactmn concept allows application programs to commit, abort, or partially undo their effects. The DO-UNDO-REDO protocol allows new recoverable types and operations to be added to the recovery system Apphcation programs can record data m the transaction log to facilitate application-specific recovery. Transaction undo and redo are based on records kept in a transaction log. The checkpoint mechanism is based on differential fries (shadows). The recovery log is recorded on disk rather than tape.

Database Recovery Using Redundant Disk Arrays

“…In the logging approach [4], before a new version (after-image) of a record or page Figure 1: RAID with rotated parity on four disks. is written to the database, a copy of the old version (before-image) is placed into a sequential log file.…”

“…A page: Dold = (P 9 P') e Dnew. When a parity group Begin-Of-Transaction (BOT) record needs to be writis dirty because one of its data pages Di has been ten to a log file after the transaction begins and before stolen from the buffer and another page Dj needs to it writes back any modified pages to disk and an EOT be written to disk, UNDO logging must be performed record must be written to the log file when the transfor Dj 4 then both parity pages P and P' need to be action commits. Modified database pages for which updated since when the group is dirty it is necessary UNDO logging has been performed, can be recovered to maintain a current parity page reflecting the actual by reading their before-images from the log.…”

Optimistic recovery in distributed systems

“…In the transaction model [3,6,7,111 computation is divided into units of work called transactions. A transaction system is expected to behave as if individual transactions were executed in some serial order (serializability), although, to reduce response time, the transactions are actually executed in parallel through multiprogramming or multiprocessing.…”

Loose-Ordering Consistency for persistent memory

“…Storage consistency ensures atomicity and durability of storage systems, so that the system is able to correctly recover from unexpected system crashes [17,18,19,20,21,22,23,24], where volatile data gets lost. In order to provide correct recovery on a system crash, multiple related persistent writes are grouped into a storage transaction by the programmer.…”

“…Traditionally, disk-based storage systems have employed transaction-based recovery protocols, such as write-ahead logging [17] or shadow paging [18], to provide both transaction atomicity and persistence ordering. These protocols maintain 1) two copies/versions of each written data within a transaction, and 2) a strict write order to the storage device, which enables the atomic switch from the old version of data to the new version upon transaction commit.…”