tx-logging vs. redundancy for databases
peter at ozzard.org
Sun May 16 17:14:35 UTC 2004
> From: [...] Chris Muller
> > When the memory content was lost, Oracle replays the redo log entires
> > that have a larger system change number (SCN) than the database
> > files. This is done in two phases: first ALL changes are applied (roll
> > forward) and then transactions that lack a commit are undone (roll
> > back) in the usual way using rollback segments..
> When memory was lost, why does it bother to apply any of the
> changes without a
> commit in the first place? Couldn't it just skip them entirely
> and only apply those that were written wholly?
Yes, but that is potentially a slower or more memory-hungry approach as it
has to identify the uncommitted transactions. With this scheme you can read
the tx log with a single sequential pass; in the common OLTP case where
there are many committed transactions and only a few, small, uncommitted
transactions, this is a big time win. Very useful for minimising system
recovery time after a crash :-).
More information about the Squeak-dev