Database Reference
In-Depth Information
Figure 6-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. 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
6-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.
The redo log buffer 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
6-2
.
Search WWH ::
Custom Search