Re: implementing a database log

Brian,

thanks for the clarification. I see your point now.

On Apr 22, 12:58 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> 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.

So your suggestion is that the log file would contain information like:

RECORD at page 13, offset 2: old key = "age", value = "30" -> modified, new key value = "40"
etc

and during recovery, i repeat these operations (or undo them)?

> 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.

I actually always thought that this was how recovery works - i think i have a neat idea for a checkpoint algorithm; my logfiles will never become very large, i hope. Rolling back/forward was something i was sure i had to do...

Thanks
Christoph Received on Tue Apr 22 2008 - 09:59:41 CEST