---

Recovering from a system crash using undo/redo-log

---

---

---

 

Slideshow:

Simplifying assumption for the initial study of recovery using UNDO/REDO logging
 
 
The recovery procedure of UNDO/REDO logging must use the general recover procedure:

The recovery algorithm for the UNDO/REDO log - part 1
 
The recovery algorithm for the UNDO/REDO log - part 2
 
Example of the recovery algorithm for the UNDO/REDO log
 
Example of a UNDO/REDO logging event sequence:

We will apply the UNDO/REDO recovery algorithm on this sample sequence....
Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 11

Recovery action(s):

Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 11

Comment:

Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 10

Recovery action(s):   (notice the database is in an inconsistent state !!)

Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 10

Comment:

Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 9

In this case, there are 2 possibilities:

Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 9

If   the <COMMIT> record was written to the UNDO/REDO log:

Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 9

If   the <COMMIT> record was written to the UNDO/REDO log:

Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 9

If   the <COMMIT> record was not written to the UNDO/REDO log:

Example of the recovery algorithm for the UNDO/REDO log - system crashed after event 9

If   the <COMMIT> record was not written to the UNDO/REDO log:

Example of the recovery algorithm for the UNDO/REDO log - system crashed on or before event 8

Recovery action(s):

A comment of UNDO/REDO logging
 
(See the recovery steps for event 9 when <COMMIT> was not written)
❮ ❯



---

---

---

---

• Simplifying assumption
  • For now, we assume that:

    The undo/redo log is append only (for simplicity)          (I.e.: no log record is ever deleted !!)

  ---

  ---

  ---

  ---

• Recovery algorithm for the undo/redo log
  • Recovery algorithm for the undo/redo log:

    /* ================================================== Step 1: identify the commited/uncommitted transactions ================================================== */ Scan the redo log: { identify the committed transaction // There is a COMMIT record identify the uncommitted/aborted transaction } /* ================================================== Step 2a: undo the uncommited/aborted transactions ================================================== */ Scan the undo log backwards: { For ( each < T, A, v, w > in the undo/redo log ) { if ( T is uncommitted/aborted ) { Update A with the (before) value v; // Undo the action !!! } } } /* ================================================== Step 2b: redo the commited transactions ================================================== */ Scan the undo log forewards: { For ( each < T, A, v, w > in the undo/redo log ) { if ( T is commited ) { Update A with the (after) value w; // Redo the action !!! } } } /* ========================================================= Step 3: mark the uncommited tranasactions as failed.... ========================================================= */ For ( each T that is uncommited ) do { Write <ABORT T> to log; } Flush-Log

  ---

  ---

  ---

  ---

• Example: using a undo/redo log
  • Example of an undo/redo log:

    ---

    ---

  • If the system crashes after step 11:

    Recovery:

    Committed transactions: T        Uncommitted transactions: None        Action: Redo Update DB element A to (new value) 1100        Update DB element B to (new value) 1900

    Comment:

    We have performed the updates needlessly (Because A and B already have the new values) However, the database state is consistent !!!

    ---

    ---

  • If the system crashes after step 10:

    Recovery:

    Committed transactions (found in log): T        Uncommitted transactions: None        Action: Redo Update DB element A to (new value) 1100        Update DB element B to (new value) 1900

    Comment:

    The DB element A has an new value !!! The DB element B has an old value !!! The database was in an inconsistent state !!! The recovery make database state consistent !!!

    ---

    ---

  • If the system crashes after step 9:

    2 possibilities:

    <COMMIT T> was written <COMMIT T> was not written

    ---

    Recovery   if   <COMMIT T> was written:

    Committed transactions: T        Uncommitted transactions: None        Action: Redo Update DB element A to (new value) 1100        Update DB element B to (new value) 1900

    Comment:

    The DB element A has an new value !!! The DB element B has an old value !!! The database was inconsistent We correctly redo the updates !!! Furthermore, the database is now in a consistent state !!!

    ---

    Recovery   if   <COMMIT T> was not written:

    Committed transactions: None        Uncommitted transactions: T        Action: undo !!!!!! Update DB element A to (old value) 1000        Update DB element B to (old value) 2000

    Comment:

    The DB element A has an new value !!! The DB element B has an old value !!! The database was inconsistent We correctly undo the updates !!! Furthermore, the database is now in a consistent state !!!

    ---

    ---

  • If the system crashes before step 8:

    Recovery:

    Committed transactions (found in log): None        Uncommitted transactions: T        Action: Undo !!!!! Update DB element A to (old value) 1000        Update DB element B to (old value) 2000

  ---

  ---

  ---

  ---

• Postscript
  • Observation:

    Just like the case in redo logging: A "committed" (finished work) transaction that does not have a <COMMIT> record, will be rolled back in the recovery

    ---

    ---

  • Solution:

    This behavior cannot be avoided completely We can only guarantee that the database state will be consistency We alleviate the problem by: Flushing the log as soon as possible when we write a <COMMIT> record