Re: implementing a database log

From: Christoph Rupp <cruppstahl_at_gmail.com>
Date: Tue, 22 Apr 2008 01:12:09 -0700 (PDT)
Message-ID: <41adcbdf-a4d8-4acb-87bc-40694d182963_at_c58g2000hsc.googlegroups.com>


Paul,

thanks for your comments

On Apr 22, 1:56 am, paul c <toledoby..._at_ac.ooyah> wrote:
> Christoph Rupp wrote:
> > 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?
>
> > thanks for your opinions,
> > chris
>
> Several advantages of logical logging, not the only ones, I'm sure:
>
> 1) Likely more insensitive to future changes in physical
> organization/operations.
>
> 2) Potential to reconstruct old db values with additional constraints
> applied (I don't know how many times this would have avoided much more
> awkward surprise requirements).
>
> 3) Ability to shadow via another physical db, eg., for read-only audit
> or various performance requirements (my favourite advantage, maybe most
> people would favour #1.)

I totally agree that logical logging is easy to implement (just dump some function calls to the log), and all your points are valid.

i.e. if there's an insert(a, b), just write the information to the logfile, and then during recovery repeat this operation. but that's also my problem: my code base is not able to repeat an operation if the database is corrupt. (and i don't think it has to work with a corrupted database).

so i don't know how to implement this. i'd be curious if any database uses logical logging - i think it's nice in theory, but just too difficult to implement... Received on Tue Apr 22 2008 - 10:12:09 CEST

Original text of this message