📄 ch08.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Teach Yourself Oracle 8 In 21 Days -- Ch 8 -- Administering Redo Logs, Control Files, and Rollback Segments</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<CENTER>
<H1><IMG SRC="../buttonart/sams.gif" WIDTH="171" HEIGHT="66" ALIGN="BOTTOM" BORDER="0"><BR>
<FONT COLOR="#000077">Teach Yourself Oracle 8 In 21 Days</FONT></H1>
</CENTER>
<CENTER>
<P><A HREF="../wk2/wk2.htm"><IMG SRC="../buttonart/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch09/ch09.htm"><IMG
SRC="../buttonart/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="../index.htm"><IMG SRC="../buttonart/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A>
<HR>
</CENTER>
<CENTER>
<H1><FONT COLOR="#000077">- Day 8 -<BR>
Administering Redo Logs, Control Files, and Rollback Segments</FONT></H1>
</CENTER>
<P>In the last few days you saw how to create a database and how to add datafiles
and tablespaces to customize that database for your own use. Remember, the instance
is made up of the files used by Oracle, the processes or threads, and the memory
used by Oracle. The files used by the database are made up of the following:
<UL>
<LI>The datafiles. These are the actual files that are used to store tablespaces.
<P>
<LI>The redo log files (sometimes just known as the <I>redo log</I>). This is where
all redo information is kept. Without the redo log files you would not be able to
recover from a system failure.
<P>
<LI>The control files. These files contain information vital to the Oracle database.
The information that is used to tell the instance where the datafiles and log files
reside is stored in the control file.
<P>
<LI>The parameter file. This file contains tuning information that is used by Oracle
at startup. This is commonly referred to as the <TT>init.ora</TT> file.
</UL>
<P>There are also the RDBMS binaries and other files such as backup files, archive
log files, and so on, but they are not really part of the database itself, even though
they are essential to the RDBMS.</P>
<P>As you saw on Day 7, "Administering Tablespaces," a tablespace can hold
four different types of segments:
<UL>
<LI>Data segment--Used to hold tables and clusters
<P>
<LI>Index segment--Used to hold indexes
<P>
<LI>Rollback segment--Special types of segments that are used to store undo information
<P>
<LI>Temporary segment--Used for storing temporary data
</UL>
<P>Today you will look at the rollback segments. Data segments, index segments, and
temp-orary segments are covered on Days 12-15. The rollback segment is not only important
to the basic function of the Oracle RDBMS, but it has performance implications as
well.
<H2><FONT COLOR="#000077"><B>Redo Log Files</B></FONT></H2>
<P>The redo log files are used to store redo information. Each time data is changed
in the database, a log record is written describing the change(s). With this information
the database can be recovered in the event of a system failure.</P>
<P>If a catastrophic system failure occurs, such as a power failure, component failure,
or similar occurrence, the Oracle instance will be aborted. The instance will be
cut off immediately or, in the event of a disk failure, the instance might crash.
If this occurs, all changed data in the buffer cache will be lost; only changes that
have been written out to disk will be saved.</P>
<P><FONT COLOR="#000077"><B>New Term:</B></FONT><B> </B>When Oracle is restarted,
the information in the redo log file will be used to reproduce changes that have
been made to the database, thus saving as much work as possible. All previously committed
transactions will be recovered; this is also known as being <I>rolled forward</I>.
All transactions that had modified data but had not been committed will be backed
out; this is known as <I>rolling back</I>.</P>
<P>The redo log file is necessary for proper recovery. If this file is lost due to
a disk failure, you will not be able to recover in the event of a system failure;
therefore, you must protect the redo log file against this kind of failure. I recommend
you use disk mirroring or RAID-1 on all redo log files.</P>
<P>Because the redo log files are so critical to the recoverability of the system,
it is recommended that you do not use a caching disk controller with write-caching
unless that cache is backed up with a battery. In the event of a power failure, you
must make sure that no redo information is lost. It is often recommended that write-caching
not be used at all on the redo log, but I feel that if you have a battery back-up
your risk is reduced.
<BLOCKQUOTE>
<P>
<HR>
<FONT COLOR="#000077"><B>WARNING:</B></FONT><B> </B>If you use a write-caching on
the controller that has the redo log files and it is not backed up with a battery,
you are in danger of losing data. In the event of a power failure, you will lose
redo information and might not be able to recover.
<HR>
</BLOCKQUOTE>
<H3><FONT COLOR="#000077"><B>How Does the Redo Log Work?</B></FONT></H3>
<P>Each change to the database is logged into the redo log. Because of this, in the
event of a failure all changes made since the last backup can be recovered with the
use of these redo log files. If the instance should fail due to a power failure or
other system failure, the redo log files can recover all changes done since the last
checkpoint.
<BLOCKQUOTE>
<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>A checkpoint causes all in-cache
data blocks that have not been written out to disk to be written out to disk. These
unwritten, changed buffers are called <I>dirty buffers</I>. These dirty buffers are
what cause the system to need to be recovered. If there are no dirty buffers when
the system fails, recovery time will be instantaneous.
<HR>
</BLOCKQUOTE>
<P>When a <TT>COMMIT</TT> operation is performed, the redo information is written
into the redo log buffers. The LGWR process writes the redo log files with the information
in the redo log buffer. The <TT>COMMIT</TT> operation is not completed until the
redo log has been written. After that has occurred, that transaction is irrevocable
and will be recovered in the event of a system failure. You can see how important
the redo log file really is.</P>
<P>The redo log is made up of two or more redo log files or log file groups. A <I>log
file group</I> is a set of files that Oracle automatically mirrors. In this manner
the redo log is protected against disk failure. A redo log group is made up of one
or more redo log files and must be protected against disk failure. If you are using
disk mirroring to protect the redo log, it is not necessary to use log file groups;
because the disk is protected, single log files are sufficient.</P>
<P><FONT COLOR="#000077"><B>New Term:</B></FONT><B> </B>The redo log has two or more
log files or log file groups that are used in an alternating fashion. When the first
log file has filled up, the logging operation moves to the next redo log file in
the chain. If archiving is enabled, when it fills up and the log switch occurs, this
file is copied to an <I>archive log file</I>. These archive log files are very important
for the recoverability of the system in the event of a catastrophic failure.</P>
<P>Operations on the redo log files are done with the <TT>ALTER DATABASE</TT> command
that was described on Day 6, "Administering Databases and Datafiles." Using
the <TT>ALTER DATABASE</TT> command you can add redo log groups, add redo log files,
rename redo log files, and so on.
<H3><FONT COLOR="#000077"><B>Log Switches and Checkpoints</B></FONT></H3>
<P><FONT COLOR="#000077"><B>New Term:</B></FONT><B> </B>Each time a redo log file
or log file group fills up, it switches to the next redo log file in the sequence.
This switch, called the <I>log switch</I>, causes several automatic events to occur:
<UL>
<LI>Checkpointing--A log switch always causes a checkpoint to occur. The checkpoint
flushes all dirty buffers from the Oracle buffer cache. This reduces the amount of
time a recovery will take, if needed.
<P>
<LI>Archiving--If archiving is turned on (and it should be), the log switch causes
the redo log file that was just active to copy its contents to an <I>archive log
file</I>. This archive log file is used in recovery if needed.
<P>
<LI>Log Sequence Number--Each time a redo log file is reused, it is given a <I>log
sequence number</I>. This log sequence number is also given to the associated archive
log file. By having this number, the RDBMS can keep track of which log file and archive
log files have been used.
</UL>
<P>Archiving and checkpointing are covered on Days 16 and 17, "Understanding
Effective Backup Techniques" and "Recovering the Database," where
backup and recovery are covered in detail.
<H4><FONT COLOR="#000077"><B>Log Switch and Checkpoint Intervals</B></FONT></H4>
<P>You can use the <TT>LOG_CHECKPOINT_INTERVAL</TT> and <TT>LOG_CHECKPOINT_TIMEOUT</TT>
initialization parameters to control the checkpoint interval. LOG_CHECKPOINT_INTERVAL
The <TT>LOG_CHECKPOINT_INTERVAL</TT> parameter is set by the administrator to a number
of operating system blocks that are used before the log switch occurs. For most operating
systems, the size of the operating system block size is 512 bytes, so this parameter
will define the number of 512-byte blocks that are used in the redo log before a
checkpoint occurs.</P>
<P>If your redo log files are 10MB in size and you want the checkpoint interval to
be one tenth of the redo log file or 1MB, use the following formula to determine
the value of <TT>LOG_CHECKPOINT_INTERVAL</TT>:</P>
<P><FONT COLOR="#0066FF"><TT>LOG_CHECKPOINT_INTERVAL</TT> = 1MB / 512 (bytes/block)
= 2,048 blocks</FONT></P>
<P>To accomplish this, set <TT>LOG_CHECKPOINT_INTERVAL = 2048</TT> in the parameter
file. To have the checkpoint occur only at log switches, set the value of <TT>LOG_CHECKPOINT_INTERVAL</TT>
to be larger than the size of your redo log files. LOG_CHECKPOINT_TIMEOUT The parameter
<TT>LOG_CHECKPOINT_TIMEOUT</TT> specifies a time interval, in seconds, at which the
checkpoint will occur. This will automatically run the checkpoint process at this
interval. To set the checkpoint to occur every 10 minutes, for example, set <TT>LOG_CHECKPOINT_TIMEOUT
= 600</TT>. By setting the checkpoint interval on a timer, you can be assured that
checkpoints will happen regularly, even if there is not much activity at the time.</P>
<P><FONT COLOR="#000077"><B>Forcing a Checkpoint</B></FONT></P>
<P>A checkpoint can be forced by hand. If you want to force a checkpoint, you can
do it with the following command:</P>
<PRE><FONT COLOR="#0066FF">ALTER SYSTEM CHECKPOINT;
</FONT></PRE>
<P>You might want to do this if you think that your system is at risk of some sort
of failure, such as from a thunderstorm or other phenomenon that might cause a power
outage or similar situation.</P>
<P><FONT COLOR="#000077"><B>Forcing a Log Switch</B></FONT></P>
<P>As with the checkpoint, a log switch can be forced by hand. If you want to force
a log switch, you can do it with the following command:</P>
<PRE><FONT COLOR="#0066FF">ALTER SYSTEM SWITCH LOGFILE;
</FONT></PRE>
<P>It is only in rare circumstances where you will need to switch log files. This
may happen when you want to force an archive before some system maintenance or other
occurrence where the system may be at risk, or you may want to do this before your
regular backup of archive log files.
<H3><FONT COLOR="#000077"><B>Sizing the Redo Log Files</B></FONT></H3>
<P>Typically the size of the redo log file is based on the capability of the medium
that will contain the archive log files. If the archive log files will be written
out to cartridge tape that can hold 525MB, you should consider making the redo log
files 520MB. This will allow you to copy one archive log file to tape and have a
little space left over for a margin of error.</P>
<P>If you do not have a particular medium in mind for archiving, or if the space
is unlimited, you should make the redo log file a manageable size. A very large redo
log file, say 2GB in size, might be a little unmanageable. Copying such a file can
take quite some time.</P>
<P>There is no rule of thumb for the size of the redo log files. Your own preference
should help you decide on it. Remember, if you make them too big you could potentially
go all day without performing a checkpoint. This can be dangerous because the longer
you go without checkpointing, the longer the recovery interval would be in the event
of a system failure.
<H3><FONT COLOR="#000077"><B>Archiving the Redo Logs</B></FONT></H3>
<P>When a log switch occurs, the log records in the filled redo log file are copied
to an archive log file if archiving is enabled. This archiving is usually done automatically.
Because the redo log file cannot be reused until the archive process has completed,
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -