Recovery Theory Non-volatile storage tape, disk, which survive - PowerPoint PPT Presentation

Storage Types  Volatile storage  main memory, which does not survive crashes. Recovery Theory  Non-volatile storage  tape, disk, which survive crashes.  Stable storage  information in stable storage is "never" lost.  There is no such physical medium; it is an approximation that is implemented. CS2550, Panos K. Chrysanthis – University of Pittsburgh CS2550, Panos K. Chrysanthis – University of Pittsburgh 1 2 Failure Types Theory of Recovery The goals of the recovery system are:  Program Failures  logical errors, bad input, unavailable data, user cancellation  When a transaction T commits   resource limits  Make the updates permanent in the database so that they  System Failures can survive subsequent failures .  computer hardware malfunction, power failures  bugs in O.S, operator error  When a transaction T aborts   Media Failures  Obliterate any updates on data items by aborted  disk head crash, data transfer error, transactions in the database.  disk controller failure  Obliterate the effects of T on other transactions; i.e.,  Unrecoverable errors transactions that read data items updated by T .  failure to make archive dumps  When the system crashes after a system or media failure   destruction of archives  Bring the database to its most recent consistent state . CS2550, Panos K. Chrysanthis – University of Pittsburgh CS2550, Panos K. Chrysanthis – University of Pittsburgh 3 4 1

Recovery Actions Recovering from Failures  Program Failures Transaction Undo  Recovery protocols implement two actions: - Removes all the updates of the  Undo action: required for atomicity. aborted transaction Undoes all updates on the stable storage by an - Does not affect any other transaction uncommitted transaction.  System Failures Global Undo  Redo action: required for durability Partial Redo Redoes the update (on the stable storage) of committed - Effects of committed transactions transaction. are reflected in the database  Media Failures Global Redo CS2550, Panos K. Chrysanthis – University of Pittsburgh CS2550, Panos K. Chrysanthis – University of Pittsburgh 5 6 Recoverable Executions (RC) Cascading Aborts  Consider the execution: To prevent unrecoverable situations the TM must keep  w 1 (x) r 2 (x) full track of read/write operations and delay commit requests of transactions.  If T 1 aborts, T 2 must also abort. Definition:   T 2 has an abort dependency on T 1 . A transaction T m reads x from transaction T n in an  In general, any transaction that reads data items updated execution if (written) by a transaction that aborts must also be aborted.   T m reads x after T n has written into it   T n does not abort before T m reads x and  What will happen if T 2 is committed before T 1 is aborted? w 1 (x) r 2 (x) c 2 α 1   ∀ T k : w Tk (x) occurred between w Tn (x) and r Tm (x) , The system cannot abort T 2 without violating the semantics of α Tk precedes r Tm (x). commit operations. CS2550, Panos K. Chrysanthis – University of Pittsburgh CS2550, Panos K. Chrysanthis – University of Pittsburgh 7 8 2

Recoverable Executions (RC) … Effects of Cascading Aborts  Significant bookkeeping of who updated what and Definition:  who read what is required. An execution is recoverable ( RC ) if for every transaction  Transactions may be forced to abort because some T n commits, T n 's commit follows the commitment of every other transaction happened to abort and all the transaction T m from which T n reads. effects of the aborted transaction need to be undone (isolation ?). RULE 0 :   Significant amount of computation may be lost due to Delay the commit of a transaction that reads cascading aborts. uncommitted data.  In practice, most DBMS are designed to avoid cascading aborts. CS2550, Panos K. Chrysanthis – University of Pittsburgh CS2550, Panos K. Chrysanthis – University of Pittsburgh 9 10 Undoing Writes Avoiding Cascading Aborts (ACA)  Definition: Assume An execution avoids cascading aborts (ACA) if whenever a transaction T n reads data updated by T m , T m has already Database = { x, y } with initial values x = 1, y = 0  committed. Transactions:  T1: write(x, 2); write(y, 3); abort  That is it ensures that every transaction reads only those values there were written by committed transactions. T2: write(x, 8); write(y, 9); abort  This means the DBMS must delay each r(x) until all transactions that previously issued a w(x) have either aborted or committed .  RULE 1: Do not permit reading of uncommitted data.  Note rule 1 is stronger than Rule 0 (the necessary condition for recoverability). CS2550, Panos K. Chrysanthis – University of Pittsburgh CS2550, Panos K. Chrysanthis – University of Pittsburgh 11 12 3

An interleaved execution The Lost Update Problem T1 T2 before image of Assume write(x, 8) x = 1 write(y, 9) y = 0 Database = { x, y } write(x, 2) x = 8 initially x = 1, y = 0 abort Transactions: write(y, 3) y = 0 T1: write(x, 2); write(y, 3); abort abort T2: write(x, 8); write(y, 9); commit  when T2 aborts Consider the following execution x = before image of w 2 (x, 8) => x = 1 w 1 (x, 2); w 2 (x, 8); w 2 (y, 9); c 2 ; w 1 (y, 3); α 1 y = before image of w 2 (y, 9) => y = 0  when T1 aborts What is the state of the database after this execution ? x = before image of w 1 (x, 2) => x = 8 y = before image of w 1 (y, 3) => y = 0 CS2550, Panos K. Chrysanthis – University of Pittsburgh CS2550, Panos K. Chrysanthis – University of Pittsburgh 13 14 Recovery Correctness Criteria Strict Executions  To solve the undoing writes problem, we must delay the execution of a write(x, val) operation until the transaction that RC ⊃ ACA ⊃ ST has previously written x terminates, i.e., commits or aborts. All Histories  Definition: RC An execution is strict (ST) if it avoids cascading aborts and ACA overwriting of uncommitted data; i.e., it is ACA and RC. ST  That is, a transaction T n can read or write a data item updated (written) by T m only after T m commits or aborts.  RULE 2: Do not permit overwriting of uncommitted data. CS2550, Panos K. Chrysanthis – University of Pittsburgh CS2550, Panos K. Chrysanthis – University of Pittsburgh 15 16 4

Reliability and Serializability All histories VSR CSR RC ACA ST RIG SERIAL CS2550, Panos K. Chrysanthis – University of Pittsburgh 17 5