Re: implementing a database log

From: David BL <davidbl_at_iinet.net.au>
Date: Tue, 29 Apr 2008 03:15:20 -0700 (PDT)
Message-ID: <c8336035-a3e0-48e0-b975-1b0c6cea9e15_at_a1g2000hsb.googlegroups.com>


On Apr 29, 5:08 pm, Eric <e..._at_deptj.demon.co.uk> wrote:
> On 2008-04-29, David BL <davi..._at_iinet.net.au> wrote:
>
>
>
> > ....
> > Ok so it relates to check pointing. I don't see how these markers are
> > particularly useful - ie to determine where to start replaying the log
> > during recovery. For example, when ARIES performs a check point it
> > records
> > 1) the active transaction list
> > 2) last LSN (Log Sequence Number) for each active transaction
> > 3) the set of dirty pages.
> > 4) for each dirty page, the LSN of the earliest log
> > record whose effect is not reflected in the page on disk.
>
> > This allows the recovery scan to determine where to start replaying
> > the log (in the REDO pass).
>
> No, I think it's about being able to recover what happened between the
> last completed checkpoint and the end of the log.

Actually with ARIES it's often necessary to recover from a position before the last completed check point!

ARIES recovery contains three passes:

  1. analysis (forwards from last check point)
  2. redo (forwards from a position calculated by the analysis)
  3. undo (backwards from the end of the log).

For efficient check pointing ARIES doesn't force all dirty pages to disk as part of the check point. Therefore on recovery ARIES often needs to begin the redo pass from a log position *before* the last valid check point.

ARIES calculates the start point of the redo pass by taking the minimum of the "recovery LSNs" of the dirty pages recorded in the checkpoint. Received on Tue Apr 29 2008 - 12:15:20 CEST

Original text of this message