Re: implementing a database log

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.

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.

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... Received on Mon Apr 21 2008 - 23:58:54 CEST