1 / 6

Recovery Concepts

Recovery Concepts. Chapter 18 (lightly). Need for Recovery. Non-catastrophic: need Log only Transaction abort Normal part of many concurrency schemes Catastrophic: need Log + Backup Physical loss of disks Pervasive application error

kingd
Download Presentation

Recovery Concepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Recovery Concepts Chapter 18 (lightly)

  2. Need for Recovery • Non-catastrophic: need Log only • Transaction abort • Normal part of many concurrency schemes • Catastrophic: need Log + Backup • Physical loss of disks • Pervasive application error • System software error (corrupted filesystem, buffer management errors, etc.) • Virus, sabotage, etc.

  3. (Review) The Log File Contains: • Transaction starts/stops • DB writes: "before" and "after" images • befores can be used to rollback an aborted transaction • afters can be used to redo a transaction without reexecuting it • COMMITs and ABORTs The log itself is as critical as the DB! Reliable backups are critical, too!

  4. Strategies Which Anticipate Normal Recovery • Deferred update • Writes are not actually applied to DB until after T commits. • No UNDO is needed. • Implementation: buffers, shadow page table, etc. • Immediate update • Writes are actually applied as T executes • Aborted transactions: UNDO (rollback)

  5. Catastrophe • First restore from a full backup • Rollforward from log • REDO all committed transactions • Apply all logged WRITEs • Could actually REDO changes in reverse chrono order: i.e., only apply latest change • T's interrupted by the catastrophe must be restarted or user notified

  6. Disaster Recovery via Redundancy • A reliable duplicate copy could be used for "instant" recovery • copy could be "hot" (in use by applications) or only on standby • SW-based • managed by DBMS or OS • could be part of a distributed system • HW-based • RAID: Redundant Array of Inexpensive Disks

More Related