Re: implementing a database log
Date: Tue, 22 Apr 2008 00:59:41 -0700 (PDT)
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"
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...
Christoph Received on Tue Apr 22 2008 - 09:59:41 CEST