Database Reference
In-Depth Information
remove some critical information and commit that operation, you can restore a backup and have Oracle restore it to
the point just before the accident using these online and archived redo log files.
Virtually every operation you perform in Oracle generates some amount of redo to be written to the online redo
log files. When you insert a row into a table, the end result of that insert is written to the redo logs. When you delete a
row, the fact that you deleted that row is written. When you drop a table, the effects of that drop are written to the redo
log. The data from the table you dropped is not written; however, the recursive SQL that Oracle performs to drop the
table does generate redo. For example, Oracle will delete a row from the
SYS.OBJ$
table (and other internal dictionary
objects), and this will generate redo, and if various modes of supplemental logging are enabled, the actual
DROP TABLE
statement will be written into the redo log stream.
Some operations may be performed in a mode that generates as little redo as possible. For example, I can create
an index with the
NOLOGGING
attribute. This means that the initial creation of the index data will not be logged, but any
recursive SQL Oracle performed on my behalf will be. For example, the insert of a row into
SYS.OBJ$
representing the
existence of the index will be logged, as will all subsequent modifications of the index using SQL inserts, updates, and
deletes. But the initial writing of the index structure to disk will not be logged.
I've referred to two types of redo log file: online and archived. We'll take a look at each in the sections that follow.
In Chapter 9 we'll take another look at redo in conjunction with undo segments, to see what impact they have on you
as a developer. For now, we'll just concentrate on what they are and what their purpose is.
Online Redo Log
Every Oracle database has at least two online redo log file groups. Each redo log group consists of one or more redo
log members (redo is managed in groups of members). The individual redo log file members of these groups are true
mirror images of each other. These online redo log files are fixed in size and are used in a circular fashion. Oracle will
write to log file group 1, and when it gets to the end of this set of files, it will switch to log file group 2 and overwrite
the contents of those files from start to end. When it has filled log file group 2, it will switch back to log file group 1
(assuming we have only two redo log file groups; if we have three, it would, of course, proceed to the third group). This
is shown in Figure
3-4
.
LOG 2
Group
LOG 3
Group
LOG 1
Group
Figure 3-4.
Writing to log file groups
The act of switching from one log file group to another is called a
log switch
. It is important to note that a log
switch may cause a temporary “pause” in a poorly configured database. Since the redo logs are used to recover
transactions in the event of a failure, we must be certain we won't need the contents of a redo log file before we are
able to use it. If Oracle isn't sure that it won't need the contents of a log file, it will suspend operations in the database
momentarily and make sure that the data in the cache that this redo “protects” is safely written (checkpointed) onto
disk. Once Oracle is sure of that, processing will resume and the redo file will be reused.
We've just started to talk about a key database concept:
checkpointing
. To understand how online redo logs are
used, you'll need to know something about checkpointing, how the database buffer cache works, and what a process
called
Database Block Writer
(
DBWn
) does. The database buffer cache and
DBWn
are covered in more detail a later on,
but we'll skip ahead a little anyway and touch on them now.
