Re: implementing a database log
Date: Mon, 21 Apr 2008 18:58:01 -0400
Message-ID: <ZZ8Pj.7736$GE1.3010_at_nlpi061.nbdc.sbc.com>
"Christoph Rupp" <cruppstahl_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.
> My problem is that one single insert can be split in up to 3 or even
> more file operations, depending on the size of the B+Tree index (it
> has to be split, if a page overflows, etc). I don't have an atomic
> "insert(key, value)" operation.
>
Perhaps you should focus on that, then.
> And in that case, i have to log 3 (or more) different file events. And
> that brings me back to my question - do i log the whole modified page
> (usually a page is between 16kb and 64kb), or just the modified region
> in the page...
>
Again, I say neither. You should log only those records that have changed: discard the notion of logging pages or segments of pages--instead, log records or sets of records. It is not enough in a concurrent environment to reconstruct a snapshot of the physical media at a particular point in time. An update may encompass many file operations; therefore, a reconstruction of just the snapshot will almost certainly be inconsistent and will require rolling back or rolling forward the result of any transactions that were outstanding at the point in time of the snapshot. Received on Tue Apr 22 2008 - 00:58:01 CEST