Redo and Undo - Expert Oracle Database Architecture - page 311

We have more new undo segment blocks in the block buffer cache. To undo the UPDATE , if necessary, we have
modified database table and index blocks in the cache. We have also generated more redo log buffer entries. Let's
assume that our redo generated from the INSERT statement (discussed in the prior section) is on disk (in the redo log
file) and redo generated from the UPDATE is in cache.

Hypothetical Scenario: The System Crashes Right Now
Upon startup, Oracle would read the redo log files and find some redo log entries for our transaction. Given the state
in which we left the system, we have the redo entries generated by the INSERT in the redo log files (which includes
redo for undo segments associated with the INSERT ). However, the redo for the UPDATE was only in the log buffer
and never made it to disk (and was wiped out when the system crashed). That's okay, the transaction was never
committed and the data files on disk reflect the state of the system before the UPDATE took place.
However, the redo for the INSERT was written to the redo log file. Therefore Oracle would “roll forward” the
INSERT . We would end up with a picture much like Figure 9-1 , with modified undo blocks (information on how to
undo the INSERT ), modified table blocks (right after the INSERT ), and modified index blocks (right after the INSERT ).
Oracle will discover that our transaction never committed and will roll it back since the system is doing crash recovery
and, of course, our session is no longer connected.
To roll back the uncommitted INSERT , Oracle will use the undo it just rolled forward (from the redo and now in
the buffer cache) and apply it to the data and index blocks, making them look as they did before the INSERT took place.
Now everything is back the way it was. The blocks that are on disk may or may not reflect the INSERT (it depends on
whether or not our blocks got flushed before the crash). If the blocks on disk do reflect the INSERT , then the INSERT
will be undone when the blocks are flushed from the buffer cache. If they do not reflect the undone INSERT , so be
it—they will be overwritten later anyway.

■ See Chapter 3 for a full discussion on checkpointing and when modified (dirty) buffers are written from the
buffer cache to disk.

Note

This scenario covers the rudimentary details of a crash recovery. The system performs this as a two-step process.
First it rolls forward, bringing the system right to the point of failure, and then it proceeds to roll back everything
that had not yet committed. This action will resynchronize the data files. It replays the work that was in progress and
undoes anything that has not yet completed.

Hypothetical Scenario: The Application Rolls Back the Transaction
At this point, Oracle will find the undo information for this transaction either in the cached undo segment blocks
(most likely) or on disk if they have been flushed (more likely for very large transactions). It will apply the undo
information to the data and index blocks in the buffer cache, or if they are no longer in the cache request, they are
read from disk into the cache to have the undo applied to them. These blocks will later be flushed to the data files with
their original row values restored.
This scenario is much more common than the system crash. It is useful to note that during the rollback process,
the redo logs are never involved. The only time redo logs are read for recovery purposes is during recovery and
archival. This is a key tuning concept: redo logs are written to. Oracle does not read them during normal processing.
As long as you have sufficient devices so that when ARCn is reading a file, LGWR is writing to a different device, there
is no contention for redo logs. Many other databases treat the log files as “transaction logs.” They do not have this
separation of redo and undo. For those systems, the act of rolling back can be disastrous—the rollback process must
read the logs their log writer is trying to write to. They introduce contention into the part of the system that can least
stand it. Oracle's goal is to make it so that redo logs are written sequentially, and no one ever reads them while they
are being written.