Redo log groups are made up of one or more redo log files. Each log file
in a group is a duplicate of the others. Oracle Corporation recommends that
redo log groups have at least two files per group, with the files distributed
on separate disks or controllers so that no single equipment failure destroys
an entire log group.
The loss of an entire current log group is one of the most serious media
failures because it can result in loss of data. The loss of a single member of
a multiple-member log group is trivial and does not affect database operation
(other than causing an alert to be published in the alert log).
Remember that multiplexing redo logs may heavily influence database
performance because a commit cannot complete until the transaction information
has been written to the logs. You must place your redo log files on your
fastest disks served by your fastest controllers. If possible, do not place any
other database files on the same disks as your redo log files (unless you are
using Automatic Storage Management [ASM]). Because only one group is written to
at a given time, there is no harm in having members from several groups on the
same disk.
Multiplexing
the Redo Log
You can
multiplex your redo log by adding a member to an existing log group. To add a
member to a redo log group (with open database and no impact on user
performance), perform the following steps:
1. Select Enterprise Manager > Server >
Redo Log Groups.
2. Select a group and click the Edit button,
or click the group number link.
The Edit Redo Log Group page appears.
The Edit Redo Log Group page appears.
3. In the Redo Log Members region, click Add.
The Add Redo Log Member page appears.
The Add Redo Log Member page appears.
4. Enter the file name and the file
directory. Click Continue.
Note: It is recommended that you store
members on separate drives to protect against total loss of the redo log
entries in the event of a disk failure.
Repeat
these steps for every existing group.
When you
add the redo log member to a group, the group’s status is marked INVALID (as
can be seen in the V$LOGFILE view). This is the expected state because a member
of the group has not yet been written to. When a log switch occurs and the
invalid group becomes the current group, the status changes to CURRENT.
Loss of
a Redo Log File
Recovering from the loss of a single redo log
group member should not affect the running instance.
To perform this recovery:
1. Determine
whether there is a missing log file by examining the alert log.
2. Restore
the missing file by copying one of the remaining files from the same group.
3. If
the media failure is due to the loss of a disk drive or controller, rename the
missing file.
4. If
the group has already been archived, or if you are in NOARCHIVELOG mode, you
may choose to solve the problem by clearing the log group to re-create the
missing file or files. Select the appropriate group and then select the Clear
Logfile action. You can also clear the affected group manually with the
following command:
SQL> ALTER DATABASE CLEAR LOGFILE GROUP #;
Note: Database Control does not allow you to
clear a log group that has not been archived. Doing so breaks the chain of redo
information. If you must clear an unarchived log group, you should immediately
take a full backup of the whole database. Failure to do so may result in a loss
of data if another failure occurs. To clear an unarchived log group, use the
following command:
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE
GROUP #;
