1 / 23

Recovery

Recovery. Backing Up Data Recovery Plans. Overview. Transactions Recovery Transaction Recovery Failure Recovery Plans. Transactions. Concept: Logical unit of work and logical unit of recovery Definition: The execution of a program that accesses or changes the contents of the database.

charlene
Download Presentation

Recovery

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 Backing Up Data Recovery Plans

  2. Overview • Transactions • Recovery • Transaction Recovery • Failure • Recovery Plans

  3. Transactions • Concept: Logical unit of work and logical unit of recovery • Definition: The execution of a program that accesses or changes the contents of the database.

  4. Example Transaction

  5. Transaction Support • Can have one of two outcomes: • Success - transaction commits and database reaches a new consistent state. • Failure - transaction aborts, and database must be restored to consistent state before it started. • Such a transaction is rolled back or undone. • Committed transaction cannot be aborted. • Aborted transaction that is rolled back can be restarted later.

  6. Transactions • Transforms database from one consistent state to another, although consistency may be violated during transaction • Application program is series of transactions with non-database processing in between.

  7. Transactions • Desirable Transaction Properties • ACID properties • Atomicity - All parts of a transaction must be completed or aborted. • Consistency - Database transformed from one consistent state to another consistent state • Note: At intermediate steps database not necxessarily consistent

  8. Isolation - Actions are not visible to other transactions until it is committed. Data used during execution of transaction cannot be used by second transaction until first one is completed, i.e. transaction’s updates concealed until after commit. • Durability (permanency)- Indicates the permanence of the database’s consistent state. After commit, changes can’t be lost.

  9. Recovery • If nothing ever goes wrong there is no need for recovery. • Recovery - restoring the database to a state that is known to be correct after some failure has rendered the current state incorrect. • Correct -does not violate any integrity rule • A database is correct iff it satisfies the logical AND of all known rules

  10. Failure - can be local or global • Transaction failures handled by: • application program • not explicitly handled by application • Categories of failures • system failures • affect all transactions but no physical damage • soft crash • Media failures • cause damage to transactions in portion of database • hard crash

  11. Recovery Facilities • DBMS should provide following facilities to assist with recovery: • Backup mechanism, which makes periodic backup copies of database. • Logging facilities, which keep track of current state of transactions and database changes. • Checkpoint facility, which enables updates to database in progress to be made permanent. • Recovery manager, which allows DBMS to restore the database to a consistent state following a failure.

  12. Transaction recovery • Transfer $500 from checking to savings given original balances • checking $1000 • savings $2000 • Begin transaction • read checking balance • subtract $500 from checking balance • write checking balance • read savings balance • add $500 to savings balance • write savings balance • End transaction • Commit

  13. Log File • Contains information about all updates to database: • Transaction records. • Checkpoint records. • Often used for other purposes (for example, auditing).

  14. Log file • Transaction records contain: • Transaction identifier. • Type of log record, (transaction start, insert, update, delete, abort, commit). • Identifier of data item affected by database action (insert, delete, and update operations). • Before-image of data item. • After-image of data item. • Log management information.

  15. Transaction Log After Image Log

  16. Transaction Log Before Image Log

  17. Check[point Checkpoint Point of synchronization between database and log file. All buffers are force-written to secondary storage. • Checkpoint record is created containing identifiers of all active transactions. • When failure occurs, redo all transactions that committed since the checkpoint and undo all transactions active at time of crash.

  18. Transactions in the Log • States • Read / Write • Commit / Abort • Checkpoints & Force Writes • Suspend execution of transactions temporarily • Force-write all update operations of committed transactions from main memory buffers to disk • Write a record to the log and force-write the log to the disk • Resume executing transactions

  19. System Failures • Contents of main memory (buffers) lost • If precise state of transaction unknown, then transaction must be UNDONE • If transaction completed but updates not transferred to disk, then transaction must be REDONE • For each of the following transactions should the system do a REDO or UNDO?

  20. Checkpoints T1 T2 TRANSACTIONS T3 T4 T5 Check Point System Failure Time T1 - completed prior to check point T2 - started prior to checkpoint, completed after checkpoint but before crash T3 - started prior to checkpoint, did not complete before crash T4 - started after checkpoint, completed before crash T5 - started after checkpoint, did not complete before crash

  21. Recovery Process • Start with 2 lists of transactions, UNDO list and REDO list. Set UNDO list equal to list of all transactions given in the most recent checkpoint record; set REDO list to empty • Search forward through the log, starting from checkpoint record • If a BEGIN TRANSACTION log entry found for transaction, T add T to UNDO list. • If COMMIT log entry is found for transaction, T, move from UNDO list to REDO list. • When end of log is reached, UNDO and REDO lists identify transactions to be undone and redone, respectively.

  22. Shadow Paging • Maintain two page tables during life of a transaction: current page and shadow page table. • When transaction starts, two pages are the same. • Shadow page table is never changed thereafter and is used to restore database in event of failure. • During transaction, current page table records all updates to database. • When transaction completes, current page table becomes shadow page table.

  23. Recovery Plans • Variety of natural or human activities can damage or render vital information assets inoperable. • Examples of natural disasters • Examples of human error disasters • Recovery plans deal with potential situations in which risk of loss varies from high to low • What is necessary to put in a recovery plan?

More Related