CHAPTER 16 Recovery System

CHAPTER 16 Recovery System

1. Failure Classification

   • There are various types of failure that may occur in a system, each of which needs to be dealt with in a different manner.
   • Logical error. The transaction can no longer continue with its normal execution because of some internal condition, such as bad input, data not found, overflow, or resource limit exceeded.
   • System error. The system has entered an undesirable state (for example, deadlock), as a result of which a transaction cannot continue with its normal execution. The transaction, however, can be reexecuted at a later time.
   • Disk failure. A disk block loses its content as a result of either a head crash or failure during a data-transfer operation. Copies of the data on other disks
   • Actions taken during normal transaction processing to ensure that enough information exists to allow recovery from failures.
   • Actions taken after a failure to recover the database contents to a state that ensures database consistency, transaction atomicity

2. Storage

   • • Volatile storage • Nonvolatile storage • Stable storage
   • To implement stable storage, we need to replicate the needed information in several nonvolatile storage media (usually disk) with independent failure mode
   • Successful completion. The transferred information arrived safely at its destination.
   • Partial failure. A failure occurred in the midst of transfer, and the destination block has incorrect information.
   • Total failure. The failure occurred sufficiently early during the transfer that the destination block remains intact.
   • We require that, if a data-transfer failure occurs, the system detects it and invokes a recovery procedure to restore the block to a consistent state.

3. Recovery and Atomicity

   • Log Records The most widely used structure for recording database modifications is the log.
     • Transaction Commit We say that a transaction has committed when its commit log record, which is the last log record of the transaction, has been output to stable storage
       • Using the Log to Redo and Undo Transactions We now provide an overview of how the log can be used to recover from a system crash, and to roll back transactions during normal operation.
   • The log is a sequence of log records, recording all the update activities in the database.
   • Transaction identifier, which is the unique identifier of the transaction that performed the write operation.
   • Data-item identifier, which is the unique identifier of the data item written. Typically, it is the location on disk of the data item, consisting of the block identifier of the block on which the data item resides, and an offset within the block.
   • Old value, which is the value of the data item prior to the write.
   • Database Modification The transaction performs some computations in its own private part of main memory.
     • The transaction modifies the data block in the disk buffer in main memory holding the data item.
     • The database system executes the output operation that writes the data block to disk.

4. Recovery Algorithm

   • Until now, in discussing recovery, we have identified transactions that need to be redone and those that need to be undone, but we have not given a precise algorithm for performing these actions.
   • a combination of the most recent checkpoint and log records to recover from a system crash.
   • Recovery After a System Crash Recovery actions, when the database system is restarted after a crash, take place in two phases
     • In the redo phase
     • In the undo phase

5. Buffer Management

   • Database Buffering The system stores the database in nonvolatile storage (disk), and brings blocks of data into main memory as needed.
   • Log-Record Buffering As a result of log buffering, a log record may reside in only main memory (volatile storage) for a considerable time before it is output to stable storage.
   • The database system reserves part of main memory to serve as a buffer that it, rather than the operating system, manages.
   • swap space. If the operating system decides to output a block B x , that block is output to the swap space on disk, and there is no way for the database system to get control of the output of buffer
   • To avoid such interruptions, the checkpointing technique can be modified to permit updates to start once the checkpoint record has been written

6. Failure with Loss of Nonvolatile Storage

   • Although failures in which the content of nonvolatile storage is lost are rare, we nevertheless need to be prepared to deal with this type of failure
   • he entire database must be copied to stable storage, resulting in considerable data transfer
     • since transaction processing is halted during

7. Early Lock Release and Logical Undo Operations

   • The insertion and deletion operations are examples of a class of operations that require logical undo operations since they release locks early; we call such operations logical operations.
     • mation about operations is called logical logging
       • new-value information is called physical logging
     • An operation is said to be idempotent if executing it several times in a row gives the same result as executing it once
       • Physical log records encountered during the scan are handled as described earlier, except those that are skipped as described shortly

8. ARIES**

   • Uses a log sequence number (LSN) to identify log records, and stores LSNsin database pages to identify which operations have been applied to a database page.
   • Supports physiological redo operations, which are physical in that the affected page is physically identified, but can be logical within the page.
   • Uses a dirty page table to minimize unnecessary redos during recovery.

9. Remote Backup Systems

   • Traditional transaction-processing systems are centralized or client–server systems.
   • Such systems are vulnerable to environmental disasters such as fire, flooding, or earthquakes.

10. Nombre: Juan Manuel Figueroa Solís Carnet: 2018139700 Universidad: I.T.C.R Curso: IC4302 Bases de Datos 2 Fecha: 27/10/21 Profesor: Erick Hernández Bonilla Grupo: 40

Bilder und Dateien der Mindmap