Re: implementing a database log

On Apr 22, 11:39 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message
>
> news: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?
>
> No, that's not what I'm suggesting. What I'm suggesting is that the atomic
> unit of work should be a /set/ of /records/--either the old records in the
> case of a before image or the new records in the case of an after image.

Ok but that sounds like the system snapshots an entire table in the before/after images.

For efficiency one would expect to only store the set of records that have been added and the set that have been removed by a given transaction. It is easy to see how we get the inverse which is required for roll back of an uncommitted transaction during recovery. However these logical operations aren't idempotent (at least for bags of records). How does recovery deal with non-idempotent redo()/ undo() changes in the log? Received on Wed Apr 23 2008 - 07:54:26 CEST