1

Generally, when a user issues an instruction to change a data block, Oracle works through 4 critical steps to make the change happen:

  1. Create a redo change vector describing the change to the data block;

  2. Create an undo record for insertion into an undo block in the undo tablespace;

  3. Create a redo change vector describing the change to the undo block;

  4. Change the data block.

Why do we need step 3 to finish the change?

Mehdi Charife
  • 722
  • 1
  • 7
  • 22
LoremIpsum
  • 1,652
  • 18
  • 27

1 Answers1

1

Let's say you have an unfinished(uncommitted) transaction. Oracle has done all things you said in the question.

Now the machine crashes.

The DBA, after the recovery of the machine(or on new machine, it depends :)) restores the last backup and applies all redo logs on the new instance. In the redo is also what was done in step 1. But that work is not committed, so the engine needs to roll it back. For this it needs the rollback segment. But rollback segment won't be there if you didn't log it on step 3.

I know you'll ask now: why it applies logs for uncommitted work? That was my question also when I read about it. I don't know for sure, but maybe it's easier to do so. Maybe is harder to check for every entry of the log that it is part of a committed transaction. However, this is how Oracle works: I applies all the redo logs then rollback uncommitted transactions.

Florin Ghita
  • 17,525
  • 6
  • 57
  • 76
  • 1
    _why it applies logs for uncommitted work?_ - the reason is that redo log works as a stream. So when you read and apply the change vectors you don't know if the changes will be committed at the end or not. Also multiple transactions can change same data block and change vector describes only changes from previous SCN to the next. And since the data files are updated asynchronously they can be many SCN behind. It's also about commit implementation approach - most of the transactions is expected to be committed only small amount rolled back. – Husqvik Nov 13 '15 at 12:44
  • @Husqvik Can we say that redo logs are agnostic to transactions? Or just is too more simple to just apply them? – Florin Ghita Nov 13 '15 at 12:59
  • @Husqvik And, because you are here, is there another reason for logging the undo? That is is the only reason I know about. – Florin Ghita Nov 13 '15 at 13:01
  • 2
    Redo includes the transaction xid. You need the undo also to achieve read consistency. When you update some data and the transaction is still active and other session access the same block it needs to be able to "see" the version as of statement/transaction start. So it needs to apply undo change vector(s) to get it. Also technically the first two steps in the original questions are switched. First entry in the redo log is the undo entry followed by data block change entry. – Husqvik Nov 13 '15 at 13:41
  • @FlorinGhita *"the engine needs to roll it back. For this it needs the rollback segment. But rollback segment won't be there if you didn't log it on step 3."* Can you please explain what do you mean by the rollback segment? It wasn't mentioned in the question. Isn't step 2 sufficient for undoing whatever redo logs were applied that were not commited? – Mehdi Charife May 08 '23 at 12:12