Oracle's Redo Log

Each Oracle database has a redo log. This redo log records all changes made in datafiles.

The redo log makes it possible to replay SQL statements.

Before Oracle changes data in a datafile it writes these changes to the redo log. If something happens to one of the datafiles, a backed up datafile can be restored and the redo, that was written since, replied, which brings the datafile to the state it had before it became unavailable.

The same technique is also used in a data guard environment (standby databases): One database (the primary database) records all changes and sends them to the standby databases. These standby databases in turn apply (reply) the arrived redo which keeps the synchronized with the primary database.

As Oracle rotates through its redo log groups, it will eventually overwrite a group which it has already written to. Data that is being overwriten would of course be useless for a recovery scenario. In order to prevent that, a database can (and for production databases should) be run in archive log mode. Simply stated, in archive log mode, Oracle makes sure that online redo log files are not overwritten unless they have been savely archived somewhere.

A database can only be recoverd from media failure if it runs under archive log.

See also Archive vs Noarchive Log Mode

LGWR writes the redo log buffers to disk.

The background process in charge for archiving redo logs is ARCn (if automatic archiving is enabled.)

In order to find out in which mode the instance runs, one can use archive log list from within sql plus.

All changes that are covered by redo is first written into the log buffer. The idea to first store it in the memory is to reduce disk IO. Of course, when a transaction commits, the redo log buffer must be flushed to disk, because otherwise the recovery for that commit could not be guaranteed. It is LGWR (Log Writer) that does that flushing.

select 
  n.name, t.value 
from 
  v$mystat   t join 
  v$statname n
on 
  t.statistic# = n.statistic#
where 
  n.name = 'redo size';

See also the package redo_diff

The RBA consists of three parts and is ten bytes long:

• Log sequence number
• Block number within this sequence
• Offset within this block

The location of each redo log entry is identified throuhg an RBA. The RBAs are important for dirty db blocks in the buffer cache.

Whenever Oracle (or more precisely, the log writer process) writes to another online redo log file group (also referred to as log switch), the log sequence number increments by one.

If the database is opened with reset logs, the log sequence number is reset to 1.

The optimal size of redo log files can be queried with

select optimal_logfile_size from v$instance_recovery; 

See also managed standby databases.

ASM simplifies the optimal layout of redo log files.

For a few operations, it is possible to minimize the generation of redo if the nologging option is set.

Redo transport services transport redo data from one server to another.

Redo is totally different from undo (rollback).

Thanks to Seghir Souidi and Hubert Savio who helped improve this page.