recovery basics n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Recovery Basics PowerPoint Presentation
Download Presentation
Recovery Basics

Loading in 2 Seconds...

play fullscreen
1 / 14

Recovery Basics - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

Recovery Basics. Types of Recovery. Catastrophic – disk crash Backup from tape; redo from log Non-catastrophic: inconsistent state Undo some operations Redo other ops. Update Times. Deferred update After transaction finish: write to log, then DB No-undo/redo Immediate update

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Recovery Basics


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. Recovery Basics

    2. Types of Recovery • Catastrophic – disk crash • Backup from tape; redo from log • Non-catastrophic: inconsistent state • Undo some operations • Redo other ops

    3. Update Times • Deferred update • After transaction finish: write to log, then DB • No-undo/redo • Immediate update • Write to log and DB before transaction finished • Undo/redo • If all transactions are written to DB before commit: undo/no-redo

    4. Recovery Concepts • Cache of DB disk pages in RAM • Dirty bit • In-place vs. shadowing • Before image (BFIM); after image (AFIM) • Log • Write-ahead logging (WAL) • Undo entries • Contains BFIM info • Redo entries • Contains AFIM info

    5. Rollback • Roll back effect of aborted transaction • Replace current info. By BFIM info. From the log • May cascade to other transactions that have read modified items

    6. All recovery operations must be idempotent: can be executed many times and have the effect of only being executed once • Implies that log values are absolute and never relative.

    7. Deferred update • A transaction cannot change the database until it reaches its commit point. • A transaction does not reach its commit point until all its update operations are recorded in the log ad the log is force-written to disk. • No-UNDO/REDO

    8. Immediate Update • database can be updated immediately without waiting for the transaction to commit, provided the log is written to disk first. • If all updates of a transaction are recorded in the database on disk before the transaction commits: UNDO/NO-REDO • If the transaction can commit before all its changes are written to the database: UNDO/REDO

    9. Shadow Paging • At the beginning of a transaction the page table is copied and stored • Write updates write a new page to disk, never modifying pages • In recovery, free the modified pages, and restore the page table. • NO-UNDO/NO-REDO • Need checkpoints and logs for concurrency control • Disadvantages: • scatters data pages • shadow page table management overhead • garbage collection overhead

    10. Two phase Commit • Need a global recovery manager • Phase 1: • each DB signals that it has finished its part of the transaction • coordinator sends “prepare to commit” message • DB’s force write logs to disk, return message “ready to commit”/”cannot commit” • Coordinator can time out and assum problem • Phase 2: • If all DB’s reply “OK”, coordinator sends commit. Recovery is possible • If some DB is “not OK”, coordinator sends “Roll back” • Failure in phase 1 requires roll back • Failure in phase 2 means a successful transaction can recover and commit.

    11. Catastrophic Failure • Backup: • whole database & log • incremental snapshots of log • Cannot cover every conceivable situation • Uptime constraints: need to freeze database as they are being backed up

    12. ARIES • Analysis • identifies dirty buffer pool pages, and active transactions at time of crash • Redo • repeats all actions in the log starting from last checkpoint • Undo • Undoes the actions of transactions that did not commit

    13. ARIES principles • WAL • Repeating History during Redo • Logging changes during Undo

    14. For more Information on ARIES see Chpt. 18 in Ramakrishnan’s DBMS book.