Re: why do you apply undo before redo?

From: Ryan <>
Date: Sun, 18 Apr 2004 16:20:45 -0400
Message-ID: <rsBgc.5061$uF3.3035_at_lakeread04>

"Jan Hidders" <> wrote in message news:Cwzgc.76768$
> Ryan wrote:
> > "Jan Hidders" <> wrote in message
> > news:Isugc.75959$
> >>Ryan wrote:
> >>>I'm reading a generic database textbook and it states that when
> >>>are recovering undo is applied before redo.
> >>
> >>Any specific reason why you would like the title of the book to remain a
> >>secret? :-)
> >
> > I didn't want to type it. Its 'Database Systems Concepts'. The one used
> > everywhere.
> Good book. But I don't know many universities around here that use it.
> Would you happen to have any statistics on that?

> >>>It doesn't say why. Does anyone know?
> >>
> >>Because some of the operations of the transactions of the UNDO list
> >>might conflict with those in the REDO list. So if you did the undo-phase
> >>last you might be erasing the result of some operations that you first
> >>did in the redo-phase.
> >
> > don't quite get this. Oracle applies redo, then rollsback all open
> > transactions? This is why that statement intrigued me since one database
> > system does it the opposite way.
> >
> > Not quite sure how the undo can conflict. You roll forward and apply all
> > change vectors, then rollback and remove what was never committed.
> Suppose that in the REDO list there is a transaction with an operation
> that changed a field from "yes" to "no", and in the UNDO list there is a
> transaction with also an operation that changed the same field also from
> "yes" to "no". Then what is the result of the field after REDO - UNDO
> and what after UNDO - REDO?\

I do not see why this matters. It does not matter what the state of the tuple is during recovery, only when it is complete. As long as you have a primary key, the values in the rest of the field do not matter until recovery is complete.

I'm at a loss on your statement. Also, oracle does it the opposite way?
> Of course most concurrency control mechanisms that guarantee
> serializability would prevent that.
> -- Jan Hidders
Received on Sun Apr 18 2004 - 22:20:45 CEST

Original text of this message