---

Quiescent checkpointing algorithm (for the undo log)

---

• Key observation in the undo log
  • Observation:

    When you find a <COMMIT T> record for transaction T, then: The undo log records written on behalf of the transaction T are now unnecessary !!!         Graphically: Reason: The undo log records is unused to roll back the updates made by transaction T in case transaction T did not write all its updates to disk due to system failure (These log records is like an insurance policy for an accident) The log record <COMMIT T> is proof (= evidence) that transaction T has writte all its updates onto the disk !!! (This is enforced by UNDO log update rule #2) The log records (insurance policy) are therefore no longer needed !!! (And can be removed/truncated !!)

    ---

    ---

  • How to to truncate an UNDO log:

    Find the first uncommitted transaction in the (undo) log: You can remove everything before this <START Tk> record, because: All log records above the first uncommitted transaction belongs to a committed transaction !!!

    ---

    ---

  • How to apply the undo log truncation technique:

    Quiescent check pointing Non-quiescent check pointing

  ---

  ---

  ---

  ---

• Quiescent undo log check pointing

  • Fact:

    Log file records are used to recover from errors while some transactions are running (executing)

    ---

    ---

  • Therefore:

    If there are no transaction executing, we do not need the log file !!!! I.e.: The content of the log file is not needed for recovery purpose !!!        (Because there are no transactions that need to be "recovered")

    ---

    ---

  • The easy way (but unpractical) to checkpoint an undo log:

    Wait until the all transactions have completed/aborted !!! Then: The whole undo log can be truncated !!!

  ---

  ---

  ---

  ---

• The quiescent checkpointing algorithm
  • Quiescent:

    Quiescent = inactive/dormant (= no transactions are running)

    ---

    ---

  • The quiescent check point algorithm on a undo log:

    1. Make the DBMS stop accepting new transactions 2. Wait until all currently active transactions to commit or abort (and have written a <COMMIT> or <ABORT> log record) 3. Flush the log to disk 4. Write <CKPT> (checkpoint) to log ---- Marks the "useful" boundary 5. Flush the log 6. Resume accepting new transactions

    ---

    ---

  • Example:

    Currently: T1 and T2 are active: Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> Now we want to perform a checkpoint: wait until T1 and T2 commit or abort Write <CKPT> Flush log Possible continuation: Undo log: <START T1> <T1, A, 5> <START T2> <T2, B, 10> <T2, C, 15> <T1, D, 20> <COMMIT T1> <COMMIT T2> <CKPT> ------------------ Useful "boundary" <START T3> <T3, E, 25> <T3, F, 30> If we want to trancate an undo log, we can remove all log record prior to the <CKPT> record

    ---

    ---

  • Result:

  ---

  ---

  ---

  ---

• Recovery procedure with checkpointing
  • Key difference:

    We do not have to scan the entire (undo) log file The (backwards) scan can stop when we find a <CKPT> record !!!

    ---

    ---

  • Recovery algorithm for undo log using quiescent checkpointing:

    /* ================================================== Step 1: identify the uncommited transactions ================================================== */ Scan the undo log backwards until first <CKPT> record: { identify the committed identify the uncommitted/aborted transactions } /* ================================================== Step 2: undo the uncommited transactions ================================================== */ Scan the undo log backwards until first <CKPT> record: { For ( each < T, A, v > in log file ) { if ( T is uncommited ) { Update A with the (before) value v; // Undo the action !!! } } } /* ========================================================= Step 3: mark the uncommited tranasactions as failed.... ========================================================= */ For ( each T that is uncommited ) do { Write <ABORT T> to log; } Flush-Log