Database Recovery Introduction

Chapter 19: Recovery System

• This chapter discusses recovery systems in database systems.

• Failure classifications are discussed

  • Transaction failures:
    • Logical errors: A transaction cannot complete due to an internal error condition.
    • System errors: The database system terminates an active transaction due to an error condition (e.g., deadlock).
  • System crashes: Power failure or other hardware/software failures causing the system to crash,
  • Disk failure: Head crash or similar disk failure destroying disk storage.

• Recovery algorithms have two primary parts:

  • Actions taken during normal transaction processing to ensure sufficient information for recovery from future failures
  • Actions taken after a failure to restore the database to a state ensuring atomicity, consistency, and durability

• Storage Structure is detailed:

  • Volatile storage: Does not survive system crashes (e.g., main memory, cache memory).
  • Nonvolatile storage: Survives system crashes (e.g., disk, tape, flash memory, nonvolatile RAM) but can still fail and lose data.
  • Stable storage: A theoretical storage that survives all failures. approximated using multiple, nonvolatile copies.

• Stable-Storage Implementation techniques:

  • Maintain multiple copies of each block on separate disks to protect against disaster (e.g., fire or flooding).
  • Execute operations (writing to both copies of each block) allowing for detection and recovery from data transfer failures.

• Recovery Algorithms are discussed:

  • Suppose a transaction transfers money between accounts, and one update fails. The recovery algorithm needs to correctly account for partial transactions.
  • Recovery algorithms have 2 key components
    • Actions to perform during normal operations to create enough information to recover after a failure
    • Actions to execute after a failure restore data to an atomic, consistent, and durable state

• Data Access explains physical and buffer blocks, along with input/output operations between main memory and disk.

• Each transaction has its work area keeping local copies of accessed data for recovery. Data transfer involves using read and write operations.

• Recovery and Atomicity: ensures atomicity despite failures by first outputting modification information to stable storage without changing the database directly, and studying log-based recovery mechanisms.

• Log-Based Recovery describes logs as sequences of log records tracking modifications for atomicity.

  • When a transaction starts, a <T; start> log record is written and registers the transaction.
  • Before a write(X) operation, a log record <T₁, X, V1, V2> is written to the log (V1 is the old value of X, V2 is the new value). When a transaction finishes execution a <T₁ commit> or <T₁ abort> log record is written.
  • Two approaches to log use: Immediate and deferred database modifications.

• Immediate Database Modification:

  • Updates occur to buffer or disk right away before the transaction commits.
  • Output of updated blocks may occur in a different order than the order the updates were written, to disk

• Deferred Database Modification:

  • Performs updates to buffer or disk only at the time that a transaction commits
  • Less overhead, but may have more storage overhead for local copies.

• Transaction Commit requires that all prior log records need to have been output to stable storage before the commit log record.

• Concurrency Control and Recovery: Concurrent transactions share the same disk buffer and log, and data updates from uncommitted transactions will be invisible. Operations are performed with locks to avoid issues.

• Undo and Redo Operations describe how to restore or repeat a transaction's updates either going backwards (undo) or forwards (redo) based on available log records or data.

• Recovering from Failure explains recovery actions when a failure occurs, and if a transaction needed to be undone or redone. Recovery involves restoring the database to a consistent or previous state if earlier actions were undone due to failure,

• Checkpoints describe how periodic logging procedures can reduce recovery overhead

  • Periodically all updated records in memory and buffer get logged to stable storage, allowing later recovery procedures to start recovery from a checkpoint point, rather than from the beginning of the log.

• Fuzzy Checkpointing: Temporary interruption in normal processing activities for updates while performing check-pointing to allow updates to take place during the procedure.

• Failure with Loss of Nonvolatile Storage discusses how to deal with failures in non-volatile storage, such as a disk failure. Recovery in this case involves restoring the database from a prior dump; checking the log to identify completed transactions, and repeating actions in this case.

• Remote Backup Systems describe systems offering high availability where transaction processing can continue even if the primary site is destroyed.

  • Detection of failure: Backup sites detect primary site failure through communication links (e.g., heartbeat messages) and distinguish links from failures to prevent incorrect recovery.
  • Transfer control is handled by first completing recovery on a backup copy of the database and received log records.
  • Recovery time is reduced by periodic backups and periodic log processes.

• Recovery with Early Lock Release and Logical Undo Operations:

  • High-concurrency locking techniques and release locks early, leading to logical undo in this recovery scheme. Operations are redone as normal.

• Logical Undo Logging: A database recovery method that executes undoing operations (deletion), rather than restoring to previous values (physical).

• Physical Redo: Redo information is logged physically (new value for each write) to avoid the complexities of logical redo.

• Operation Logging method for logging operations (starts and ends):

  • A unique operation identifier (Oj) is used for logging.
  • Records with physical redo and undo information are logged during operation execution.
  • Includes operation-begin and operation-end markers.

• Transaction Rollback with Logical Undo: Describes how transaction rollback is done during normal operations.

• Recovery Algorithm with Logical Undo involves redo and undo phases after a crash

• ARIES Recovery Algorithm: A recovery method that uses optimization techniques, including log sequence numbers, to speed up the recovery process. It includes three passes (Analysis, Redo and Undo).

• ARIES Data Structures: Includes log sequence numbers (LSN), dirty page tables, and checkpoint log, to increase efficiency.

• Checkpoint Log tracks what changes have already been performed physically.

• ARIES Recovery Algorithm, also involves three passes to determine which transactions need to be rolled back or redone.

  • Analysis phase: Identifies transactions that need undo or redo, identifies the LSN for the redo to start from.
  • Redo phase: Re-executes actions from the redoLSN, avoiding re-doing actions already done.
  • Undo phase: Re-executes undo actions for incomplete transactions

• Other ARIES Features may involve fine-grained locking, recovery independence, and savepoints, which allow for more sophisticated concurrency control and recovery.

• Recovery in Main Memory Databases are recovery processes on main memory databases and optimizations.

• Shadow Paging; a system to copy pages and recover from changes; efficient for serial execution but it is expensive for copying a large table.

• Block Storage explains how data is stored and retrieved on disk and in memory, using input (A) and output (B) operations for managing transfer.

This quiz explores essential concepts related to database recovery processes, focusing on non-volatile storage, transaction management, and data item access. Learn about the operations involved in restoring, undoing, and logging changes in a database system. Prepare to understand critical recovery mechanisms and their significance.