Re: implementing a database log

From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 21 Apr 2008 17:00:03 -0400
Message-ID: <nf7Pj.1605$26.351_at_newssvr23.news.prodigy.net>


"Christoph Rupp" <cruppstahl_at_gmail.com> wrote in message news:be664140-d43e-4012-8b07-52a49ff3a4bf_at_t54g2000hsg.googlegroups.com...
> Hi,
>
> i'm the author of a simple open-source database engine. i'm currently
> adding recovery/logging, and i have some practical questions about the
> implementation.
>
> I have 3 options.
>
> 1. a physical log based on modified pages - whenever a page is
> modified, a before/after image is stored in the log.
> pro: easy to implement and to test
> con: logfile will become huge!
>
> 2. a physical log based on modified bytes - whenever a database key or
> record is modified, only the modified bytes in the file are logged.
> pro: logfile is slim, very fine-grained control
> con: tedious to implement, error prone, difficult to test
>
> 3. a logical logging - information about the high-level operation is
> stored in the logfile. honestly, i don't know how i could implement
> this, since one high-level operation is often splitted into several
> physical operations, and if one of them fails i am not sure about the
> consequences...
>
> currently, i'm going with 2), but as i wrote above, it's hard to
> implement and i'm not happy with the way i'm going.
>
> what would you recommend?
>

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.

> thanks for your opinions,
> chris
Received on Mon Apr 21 2008 - 23:00:03 CEST

Original text of this message