Re: implementing a database log

From: David BL <davidbl_at_iinet.net.au>
Date: Mon, 21 Apr 2008 23:53:42 -0700 (PDT)
Message-ID: <265621e9-25fd-46d5-9e2d-7a4f63fa84b4_at_m3g2000hsc.googlegroups.com>


On Apr 22, 6:58 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Christoph Rupp" <cruppst..._at_gmail.com> wrote in message
>
> news:91140c56-1f05-4b5d-b45f-b34920db2051_at_x41g2000hsb.googlegroups.com...
>
> > Brian,
>
> > On Apr 21, 11:00 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> Why not go with #4:
>
> >> 4. a physical log based on modified rows. Whenever a row is modified,
> >> added
> >> or removed, it is logged. Then you could also implement row
> >> versioning--just add a row version field to the physical rows. I believe
> >> that this what snapshot isolation is built on.
>
> > It's not an SQL database, i don't even have the notion of "rows", but
> > basically i think your #4 is the same as my #1 or #2.
>
> No, it isn't. #1 requires the logging of additional records that may not
> have been affected by an update. #2 doesn't log the entire changed record,
> but only bits and pieces. I would think that limiting the units of change
> to individual records--entire records--would simplify the process of marking
> and isolating units of work while at the same time guaranteeing consistency.

I don't think an atomic unit of work is always associated with a change to an individual record. Are you suggesting transactions to define arbitrarily large units of work aren't needed?

Typically a log will contain special log records to mark transaction boundaries. Many systems allow interleaving of transaction log records by using a transaction id in each log record. Each transaction is normally expected to end with a commit or abort log record.

This is irrespective of whether physical or logical changes are logged. Received on Tue Apr 22 2008 - 08:53:42 CEST

Original text of this message