Redo and Undo - Expert Oracle Database Architecture - page 309

Block Buffer
Cache

Redo Log
Buffer

Undo Indexes Table T

Figure 9-1. State of the system after an INSERT

There are some cached, modified undo blocks, index blocks, and table data blocks. Each of these blocks is
protected by entries in the redo log buffer.

Hypothetical Scenario: The System Crashes Right Now
In this scenario, the system crashes before a COMMIT is issued or before the redo entries are written to disk (see Chapter
4 for details on mechanisms that cause redo to be written to disk). Everything is OK. The SGA is wiped out, but we
don't need anything that was in the SGA. It will be as if this transaction never happened when we restart. None of the
blocks with changes got flushed to disk, and none of the redo got flushed to disk. We have no need of any of this undo
or redo to recover from an instance failure.

Hypothetical Scenario: The Buffer Cache Fills Up Right Now
The situation is such that DBWn must make room and our modified blocks are to be flushed from the cache. In this
case, DBWn will start by asking LGWR to flush the redo entries that protect these database blocks. Before DBWn can write
any of the blocks that are changed to disk, LGWR must flush (to disk) the redo information related to these blocks.
This makes sense: if we were to flush the modified blocks for table T (but not the undo blocks associated with the
modifications) without flushing the redo entries associated with the undo blocks, and the system failed, we would
have a modified table T block with no undo information associated with it. We need to flush the redo log buffers
before writing these blocks out so that we can redo all of the changes necessary to get the SGA back into the state it is
in right now, so that a rollback can take place.
This second scenario shows some of the foresight that has gone into all of this. The set of conditions described
by “If we flushed table T blocks and did not flush the redo for the undo blocks and the system failed” is starting to get
complex. It only gets more complex as we add users, and more objects, and concurrent processing, and so on.
At this point, we have the situation depicted in Figure 9-1 . We have generated some modified table and index
blocks. These have associated undo segment blocks, and all three types of blocks have generated redo to protect
them. If you recall from our discussion of the redo log buffer in Chapter 4, it is flushed at least every three seconds,
when it is one-third full or contains 1MB of buffered data, or whenever a COMMIT or ROLLBACK takes place. It is very
possible that at some point during our processing, the redo log buffer will be flushed. In that case, the picture will
look like Figure 9-2 .