What Is the Redo Log?

The most crucial structure for recovery operations is the redo log, which consists of
two or more preallocated 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 failu

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.
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 entries record data that you can use to reconstruct all changes made to the
database, including the undo segments. Therefore, the redo log also protects
rollback data. When you recover the database using redo data, the database reads
the change vectors in the redo records and applies the changes to the relevant
blocks
Redo records are buffered in a circular fashion in the redo log buffer of the SGA (see
"How Oracle Database Writes to the Redo Log") and are written to one of the redo
log files by the Log Writer (LGWR) database background process. Whenever a
transaction is committed, LGWR writes the transaction redo records from the redo

log buffer of the SGA to a redo log file, and assigns a system change number (SCN)
to identify the redo records for each committed transaction. Only when all redo
records associated with a given transaction are safely on disk in the online logs is
the user process notified that the transaction has been committed
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
while the other is being archived (if the database is in ARCHIVELOG mode).
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. Figure 10-1 illustrates the circular writing of the redo log file. The
numbers next to each line indicate the sequence in which LGWR writes to each redo
log file.

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 datafiles.

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
datafiles and the file has been archived.
Active (Current) and Inactive Redo Log Files

Oracle Database uses only one redo log files 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.

If you have enabled archiving (the database is in ARCHIVELOG mode), then the
database cannot reuse or overwrite an active online log file until one of the archiver
background processes (ARCn) has archived its contents. If archiving is disabled (the
database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR
continues by overwriting the first available active file.
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. When the database archives redo
log files, the archived log retains its log sequence number. A redo log file that is
cycled back for use is given the next available log sequence number.

Each online or archived redo log file is uniquely identified by its log sequence
number. During crash, instance, or media recovery, the database properly applies
redo log files in ascending order by using the log sequence number of the necessary
archived and redo log files.
Choosing Between NOARCHIVELOG and ARCHIVELOG Mode

This section describes the issues you must consider when choosing to run your
database in NOARCHIVELOG or ARCHIVELOG mode, and contains these topics:

Running a Database in NOARCHIVELOG Mode

Running a Database in ARCHIVELOG Mode

The choice of whether to enable the archiving of filled groups of redo log files
depends on the availability and reliability requirements of the application running
on the database. If you cannot afford to lose any data in your database in the event

of a disk failure, use ARCHIVELOG mode. The archiving of filled redo log files can
require you to perform extra administrative operations.
Running a Database in NOARCHIVELOG Mode

When you run your database in NOARCHIVELOG mode, you disable the archiving of
the redo log. The database control file indicates that filled groups are not required to
be archived. Therefore, when a filled group becomes inactive after a log switch, the
group is available for reuse by LGWR.

NOARCHIVELOG mode protects a database from instance failure but not from media
failure. Only the most recent changes made to the database, which are stored in the
online redo log groups, are available for instance recovery. If a media failure occurs
while the database is in NOARCHIVELOG mode, you can only restore the database to
the point of the most recent full database backup. You cannot recover transactions
subsequent to that backup.

In NOARCHIVELOG mode you cannot perform online tablespace backups, nor can
you use online tablespace backups taken earlier while the database was in
ARCHIVELOG mode. To restore a database operating in NOARCHIVELOG mode, you
can use only whole database backups taken while the database is closed. Therefore,
if you decide to operate a database in NOARCHIVELOG mode, take whole database
backups at regular, frequent intervals.
Running a Database in ARCHIVELOG Mode

When you run a database in ARCHIVELOG mode, you enable the archiving of the
redo log. The database control file indicates that a group of filled redo log files
cannot be reused by LGWR until the group is archived. A filled group becomes
available for archiving immediately after a redo log switch occurs.

The archiving of filled groups has these advantages:

A database backup, together with online and archived redo log files, guarantees
that you can recover all committed transactions in the event of an operating system
or disk failure.

If you keep an archived log, you can use a backup taken while the database is
open and in normal system use.

You can keep a standby database current with its original database by
continuously applying the original archived redo logs to the standby.

You can configure an instance to archive filled redo log files automatically, or you
can archive manually. For convenience and efficiency, automatic archiving is usually
best. Figure 11-1 illustrates how the archiver process (ARC0 in this illustration)
writes filled redo log files to the database archived redo log.

If all databases in a distributed database operate in ARCHIVELOG mode, you can

perform coordinated distributed database recovery. However, if any database in a
distributed database is in NOARCHIVELOG mode, recovery of a global distributed
database (to make all databases consistent) is limited by the last full backup of any
database operating in NOARCHIVELOG mode
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Oracle Database lets you save filled groups of redo log files to one or more offline
destinations, known collectively as the archived redo log. The process of turning
redo log files into archived redo log files is called archiving. This process is only
possible if the database is running in ARCHIVELOG mode.

What Is the Archived Redo Log?

Oracle Database lets you save filled groups of redo log files to one or more offline
destinations, known collectively as the archived redo log. The process of turning
redo log files into archived redo log files is called archiving. This process is only
possible if the database is running in ARCHIVELOG mode. You can choose automatic
or manual archiving.

An archived redo log file is a copy of one of the filled members of a redo log group.
It includes the redo entries and the unique log sequence number of the identical
member of the redo log group. For example, if you are multiplexing your redo log,
and if group 1 contains identical member files a_log1 and b_log1, then the archiver
process (ARCn) will archive one of these member files. Should a_log1 become
corrupted, then ARCn can still archive the identical b_log1. The archived redo log
contains a copy of every group created since you enabled archiving.

When the database is running in ARCHIVELOG mode, the log writer process (LGWR)
cannot reuse and hence overwrite a redo log group until it has been archived. The
background process ARCn automates archiving operations when automatic
archiving is enabled. The database starts multiple archiver processes as needed to
ensure that the archiving of filled redo logs does not fall behind.

You can use archived redo logs to:

Recover a database

Update a standby database

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@2
f your database is running in ARCHIVELOG mode, it copies all transactions to the
archivelog destination. The transactions are always written to the redolog files but
when they are full, they are only saved when running in archivelog mode. This
enables you to restore your database to any point in time. This restore operation
starts with restoring a full backup where you can apply the archives until you reach
the point in time where you want to stop the recovery. For example, close before a
table was dropped.

Normally production backups are made with the database online. Again, a reason to
run your databases in archivelog mode. IF not running archivelog mode, in a
disaster scenario you might loose all transactions made since the last backup. If
your transactions are really important it could be smart to copy the archivedlog files
to a second DC on a very regularly basis. How regularly depends on the cost of
loosing transactions. If you can handle loosing one day, you copy daily, most sites
copy a few times/hour or even use standby databases that receive the transactions
in a near sync way.

In general you start restoring the database and perform a recovery until time.
Normally we use rman to do this, something like

rman
run
{

set until time to_date('20140914 14:22','yyyymmdd hh24:mi');

restore database;
recover database;
}

when ready and not done a full media recovery, open the database with a reset logs
option.

alter database open resetlogs;

To prevent nightmares from happening, it might be smarter to get involvement from

a dba.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Deciding Between ARCHIVELOG and NOARCHIVELOG Mode

The redo logs of your database provide a complete record of changes to the
datafiles of your database (with a few exceptions, such as direct path loads).

You can run your database in one of two modes: ARCHIVELOG mode or
NOARCHIVELOG mode. In ARCHIVELOG mode, a used online redo log group must be
copied to one or more archive destinations before it can be reused. Archiving the
redo log preserves all transactions stored in that log, so that they can be used in
recovery operations later. In NOARCHIVELOG mode, the online redo log groups are
simply overwritten when the log is reused. All information about transactions
recorded in that redo log group is lost.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2.3.3.1 Implications of Running in NOARCHIVELOG Mode

Running your database in NOARCHIVELOG mode imposes severe limitations on

your backup and recovery strategy.

You cannot perform online backups of your database. You must shut your
database down cleanly before you can take a backup in NOARCHIVELOG mode.

You cannot use any data recovery techniques that require the archived redo
logs. These include complete and point-in-time media recovery, as described in
"Forms of Data Recovery", and more advanced recovery techniques such as pointin-time recovery of individual tablespaces and Flashback Database (described in
Oracle Database Backup and Recovery Advanced User's Guide.).

If you are running in NOARCHIVELOG mode and you must recover from damage
to datafiles due to disk failure, you have two main options for recovery:

Drop all objects that have any extents located in the affected files, and then
drop the files. The remainder of the database is intact, but all data in the affected
files is lost.

Restore the entire database from the most recent backup, and lose all changes
to the database since the backup. (Recovering changes since the backup would
require performing media recovery, which uses the archived redo logs.)

...

When performance requirements are extreme or disk space limitations are

severe, it may be preferable to run in NOARCHIVELOG mode in spite of the
limitations that this choice imposes upon your recovery options.

You almost always will want to run in ARCHIVELOG mode, therefore you almost
always want to backup your archive logs.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2
Administer the Archived Redo Logs

An Oracle database can run in one of two modes. By default, the database is
created in NOARCHIVELOG mode. This command will check to see if you have
altered your database to run in ARCHIVELOG mode. See my notes on how to check
if running in ARCHIVELOG mode.

$ sqlplus /nolog

SQL> connect / as sysdba;

connected.

SQL> archive log list;

SQL> select log_mode from v$database;

When in NOARCHIVELOG mode the database runs normally, but there is no capacity
to perform any type of point in time recovery operations or online backups. Thus,
you have to shutdown the database to back it up, and when you recover the
database you can only recover it to the point of the last backup. While this might be
fine for a development environment, the big corporate types tend to frown when a
weeks worth of current production accounting data is lost forever.
Using the ARCHIVELOG Mode

So, if you wish to avoid the wrath of the CEO and angry end-users, you will want to
run Oracle in ARCHIVELOG mode. In ARCHIVELOG mode, the database will make
copies of all online redo logs after they are filled. These copies are called archived
redo logs. The archived redo logs are created via the ARCH process. The ARCH
process copies the archived redo log files to one or more archive log destination
directories.

The use of ARCHIVELOG mode requires some configuration of the database. First
you must put the database in ARCHIVELOG mode and you must also configure the
ARCH process, and prepare the archived redo log destination directories.

There are some down sides to running the database in ARCHIVELOG mode. For
example, once an online redo log has been filled, it cannot be reused until it has
been archived. If Oracle cannot archive the online redo log (for example, the
destination directory for the archived redo logs is filled up), it will switch to the next
online redo log and keep working. At the same time, Oracle will continue to try to
archive the log file.

Unfortunately, once the database runs out of available online redo logs, we have a
problem. If the log files can not be written out, then Oracle would have to overwrite
them. This is not good because it means we would lose the data that was in those

files since Oracle could not archive the file. As a result of this, in an effort to protect
the database, Oracle will not overwrite data in an online redo log file until that log
file has been archived. Until the file has been archived, the database will simply
stop processing user requests. Once the log file has been archived, the database
will be freed, and processing can proceed as normal.

You can see how an incorrect configuration of the database when it is in

ARCHIVELOG mode can eventually lead to the database suspending operations
because it can not archive the current online redo logs.

In the next sections we will look at how to configure the database for ARCHIVELOG
mode and how to put the database in ARCHIVELOG mode.
Configuring the database for ARCHIVELOG Mode

One of the main features of a database that is in ARCHIVELOG mode is that it

generates copies of the online redo logs called archived redo logs. By default in
Oracle Database 10g and beyond, Oracle will send archived redo logs to the flash
recovery area and we recommend this configuration.

To properly setup the flash recovery area, you will want to set two parameters as
seen in the following list:

db_recovery_file_dest - ORACLE_BASE/flash_recovery_area - This is the location of

the flash recovery area.

db_recovery_file_dest_size - 2g - This is the maximum size that can be used by

the flash recovery area. If this size limit is exceeded, you must clear out space or
database operations will eventually stall.

Use the alter system command to set these parameters if you do not want to use
the default values. You will find examples of the use of the alter system command
to change parameters earlier in this chapter. We recommend that the
db_recovery_file_dest parameter be set to a directory location that is separate from
the location of the Oracle software, your redo logs, and your data files. You do not
want to accidentally fill up ORACLE_HOME or cause performance issues due to
contention.

When the flash recovery area is configured, a directory for the database will be
created in the location defined by the db_recovery_file_dest parameter. For
example, our database has a directory called:

C:\Oracle\product\flash_recovery_area\BOOKTST

Under this directory are individual directories for various file types such as
ARCHIVELOG where the archived redo logs will reside.

In earlier versions of Oracle you had to enable a special Oracle process called ARCH
by setting another parameter. Oracle Database 10g does not require this. When the
database is in ARCHIVELOG mode, it will start the ARCH process automatically.
Putting the database in ARCHIVELOG Mode

Once you have configured the flash recovery area, you can put the database in
ARCHIVELOG mode. Unfortunately, this requires that the database be shutdown first
with the shutdown command (however, from earlier in the chapter, we note that
shutdown immediate is the best option). Once you have shutdown the database,
you will start the database in mount mode with the startup mount command. Then
put the database in ARCHIVELOG mode, and finally open the database. Here is an
example of how this all works from the command line:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 272629760 bytes

Fixed Size
Variable Size

788472 bytes
103806984 bytes

Database Buffers

167772160 bytes

Redo Buffers

262144 bytes

Database mounted.

SQL> alter database archivelog;

Database altered.
SQL> alter database open;
Database altered.

Once the database is in ARCHIVELOG mode, it will start generating archived redo
logs. It's always a good idea to make sure that the archived redo logs are getting
generated. To do this, first force a log switch with the alter system switch logfile
command. Then check the flash recovery area to make sure an archived redo log is
created.

Note! Oracle flash recovery area re-named to fast recovery area

The archived redo logs will be in the flash recovery area in the ARCHIVELOG
directory. Under that directory you will find individual directories, each represents a
different date such as 2005_03_09 for March 3, 1005. The directory structure on my
computer looks like this:

C:\Oracle\product\flash_recovery_area\BOOKTST\ARCHIVELOG\2005_03_09

It might look a little different on your computer (sometimes Oracle does different
things on different Operating Systems) but it should be pretty easy to figure it out.

Now, go to the directory that is named for today?s date. In my case, I?ll go to the
2005_03_16 directory. Next, we do a directory listing in that directory and you
should see archived redo logs in the directory. Here is an example of what you will
see on your computer:
C:\Oracle\product\flash_recovery_area\BOOKTST\ARCHIVELOG\2005_03_16

>dir
Volume in drive C has no label.
Volume Serial Number is 50FD-2353

Directory of
c:\Oracle\product\flash_recovery_area\BOOKTST\ARCHIVELOG\2005_03_16

If you are seeing files get generated here, you know archiving is working all right.
Archived Redo Log Data Dictionary Views

Oracle provides data dictionary views for the archived redo logs as seen in this list:

v$archived_log - Information about archived redo logs.

v$parameter - Shows the location of the flash recovery area where archived redo
logs are created.

v$log_history - Contains information on previous redo logs

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@