Re: why do you apply undo before redo?
Date: Sun, 18 Apr 2004 16:20:45 -0400
"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
> Ryan wrote:
> > "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
> > news:Isugc.75959$VI4.5039222_at_phobos.telenet-ops.be...
> >>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