What Is the Redo Log?

The most crucial structure for recovery operations is the redo log, which
consists of two or more pre-allocated files that store all changes made
to the database as they occur. Every instance of an Oracle Database has
an associated redo log to protect the database in case of an instance
failure.
When speaking in the context of multiple database instances, the redo
log for each database instance is also referred to as a redo thread.
Redo Log Contents
• Redo log files are filled with redo records. A redo record, also called a redo
entry, is made up of a group of change vectors, each of which is a
description of a change made to a single block in the database. For
example, if you change a salary value in an employee table, you generate a
redo record containing change vectors that describe changes to the data
segment block for the table, the undo segment data block, and the
transaction table of the undo segments.
• Redo records can also be written to a redo log file before the
corresponding transaction is committed. If the redo log buffer fills, or
another transaction commits, LGWR flushes all of the redo log entries in
the redo log buffer to a redo log file, even though some redo records may
not be committed. If necessary, the database can roll back these changes.
How Oracle Database Writes to the Redo Log
• The redo log of a database consists of two or more redo log files. The database
requires a minimum of two files to guarantee that one is always available for
writing.
• LGWR writes to redo log files in a circular fashion. When the current redo log file
fills, LGWR begins writing to the next available redo log file. When the last
available redo log file is filled, LGWR returns to the first redo log file and writes to
it, starting the cycle again.
Filled redo log files are available to LGWR for reuse depending on whether
archiving is enabled.
■ If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log
file is available after the changes recorded in it have been written to the data files.
■ If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file
is available to LGWR after the changes recorded in it have been written to the data
files and the file has been archived.
Active (Current) and Inactive Redo Log Files
• Oracle Database uses only one redo log file at a time to store redo records
written from the redo log buffer. The redo log file that LGWR is actively
writing to is called the current redo log file.
• Redo log files that are required for instance recovery are called active redo
log files. Redo log files that are no longer required for instance recovery are
called inactive redo log files.
Log Switches and Log Sequence Numbers
• A log switch is the point at which the database stops writing to one redo log
file and begins writing to another. Normally, a log switch occurs when the
current redo log file is completely filled and writing must continue to the
next redo log file. However, you can configure log switches to occur at
regular intervals, regardless of whether the current redo log file is
completely filled. You can also force log switches manually.
• Oracle Database assigns each redo log file a new log sequence number
every time a log switch occurs and LGWR begins writing to it. Each online or
archived redo log file is uniquely identified by its log sequence number.
 Planning the Redo Log
• Multiplexing Redo Log Files
To protect against a failure involving the redo log itself, Oracle Database
allows a multiplexed redo log, meaning that two or more identical copies
of the redo log can be automatically maintained in separate locations.
For the most benefit, these locations should be on separate disks.
Multiplexing is implemented by creating groups of redo log files. A group
consists of a redo log file and its multiplexed copies. Each identical copy
is said to be a member of the group. Each redo log group is defined by a
number, such as group 1, group 2, and so on.
• Responding to Redo Log Failure: Whenever LGWR cannot write to a
member of a group, the database marks that member as INVALID and
writes an error message to the LGWR trace file and to the database
alert log to indicate the problem with the inaccessible files.
• Legal and Illegal Configurations: In most cases, a multiplexed redo log
should be symmetrical: all groups of the redo log should have the
same number of members. However, the database does not require
that a multiplexed redo log be symmetrical. For example, one group
can have only one member, and other groups can have two members.
This configuration protects against disk failures that temporarily affect
some redo log members but leave others intact. The only
requirement for an instance redo log is that it have at least two
groups.
Placing Redo Log Members on Different Disks
When setting up a multiplexed redo log, place members of a group on different
physical disks. If a single disk fails, then only one member of a group becomes
unavailable to LGWR and other members remain accessible to LGWR, so the
instance can continue to function.
Planning the Size of Redo Log Files
When setting the size of redo log files, consider whether you will be archiving the
redo log. Redo log files should be sized so that a filled group can be archived to a
single unit of offline storage media (such as a tape or disk), with the least amount
of space on the medium left unused. For example, suppose only one filled redo
log group can fit on a tape and 49% of the tape storage capacity remains unused.
In this case, it is better decrease the size of the redo log files slightly, so that two
log groups could be archived on each tape.
Planning the Block Size of Redo Log Files: Redo log files always default to a block
size that is equal to the physical sector size of the disk. Historically, this has
typically been 512 bytes (512B).
Choosing the Number of Redo Log Files
In some cases, a database instance may require only two groups. In other
situations, a database instance may require additional groups to guarantee
that a recycled group is always available to LGWR.
Consider the parameters that can limit the number of redo log files before
setting up or altering the configuration of an instance redo log. The
following parameters limit the number of redo log files that you can add to
a database:
• The MAXLOGFILES parameter used in the CREATE DATABASE statement
determines the maximum number of groups of redo log files for each
database. Group values can range from 1 to MAXLOGFILES.
• The MAXLOGMEMBERS parameter used in the CREATE DATABASE
statement determines the maximum number of members for each
groupm.
Creating Redo Log Groups and Members
Plan the redo log of a database and create all required groups and
members of redo log files during database creation. However, there are
situations where you might want to create additional groups or
members. For example, adding groups to a redo log can correct redo
log group availability problems.
• To create new redo log groups and members, you must have the
ALTER DATABASE system privilege. A database can have up to
MAXLOGFILES groups.
• Creating Redo Log Groups
To create a new group of redo log files, use the SQL statement ALTER
DATABASE with the ADD LOGFILE clause.
• Creating Redo Log Members: In some cases, it might not be necessary to
create a complete group of redo log files. A group could already exist, but
not be complete because one or more members of the group were
dropped (for example, because of a disk failure). In this case, you can add
new members to an existing group.
• To create new redo log members for an existing group, use the SQL
statement ALTER DATABASE with the ADD LOGFILE MEMBER clause.
 Relocating and Renaming Redo Log Members
You can use operating system commands to relocate redo logs, then use the
ALTER DATABASE statement to make their new names (locations) known to
the database. This procedure is necessary, for example, if the disk currently
used for some redo log files is going to be removed, or if data files and several
redo log files are stored on the same disk and should be separated to reduce
contention.
To rename redo log members, you must have the ALTER DATABASE system
privilege. Additionally, you might also need operating system privileges to
copy files to the desired location and privileges to open and back up the
database.
Before relocating your redo logs, or making any other structural changes to
the database, completely back up the database in case you experience
problems while performing the operation. As a precaution, after renaming or
relocating a set of redo log files, immediately back up the database control
file.
Steps for Renaming Redo Log Members
1. Shut down the database.
SHUTDOWN
2. Copy the redo log files to the new location.
3. Startup the database, mount, but do not open it.
CONNECT / as SYSDBA
STARTUP MOUNT
4. Rename the redo log members.
Use the ALTER DATABASE statement with the RENAME FILE clause to rename
the database redo log files.
5. Open the database for normal operation.
The redo log alterations take effect when the database is opened.
ALTER DATABASE OPEN;
Dropping Redo Log Groups and Members
• In some cases, you may want to drop an entire group of redo log
members. For example, you want to reduce the number of groups in
an instance redo log. In a different case, you may want to drop one or
more specific redo log members. For example, if a disk failure occurs,
you may need to drop all the redo log files on the failed disk so that
the database does not try to write to the inaccessible files. In other
situations, particular redo log files become unnecessary. For example,
a file might be stored in an inappropriate location.
you must have the ALTER DATABASE system privilege. Before dropping a
redo log group, consider the following restrictions and precautions:
■ An instance requires at least two groups of redo log files, regardless of
the number of members in the groups. (A group comprises one or more
members.)
■ You can drop a redo log group only if it is inactive. If you must drop the
current group, then first force a log switch to occur.
■ Make sure a redo log group is archived (if archiving is enabled) before
dropping it.
The following statement drops redo log group number 3:
ALTER DATABASE DROP LOGFILE GROUP 3;
 Assignment and presentation

Managing Table spaces,