Overview of the Online Redo Log
The most crucial structure for recovery is the online redo log, which consists of two or more pre allocated files that store changes to the database as they occur. The online redo log records changes to the data files.
Use of the Online Redo Log
The database maintains online redo log files to protect against data loss. Specifically, after an instance failure the online redo log files enable Oracle Database to recover committed data not yet written to the data files.
Oracle Database writes every transaction synchronously to the redo log buffer, which is then written to the online redo logs. The contents of the log include uncommitted transactions, undo data and schema and object management statements.
How Oracle Database Writes to the Online Redo Log
The online redo log for a database instance is called a redo thread. In single-instance configurations, only one instance accesses a database, so only one redo thread is present. In an Oracle Real Application Clusters (Oracle RAC) configuration, however, two or more instances concurrently access a database, with each instance having its own redo thread. A separate redo thread for each instance avoids contention for a single set of online redo log files. An online redo log consists of two or more online redo log files. Oracle 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 ARCHIVE LOG mode).
Online Redo Log Switches
Oracle Database uses only one online redo log file at a time to store records written from the redo log buffer. The online redo log file to which the log writer (LGWR) process is actively writing is called the current online redo log file. A log switch occurs when the database stops writing to one online redo log file and begins writing to another. Normally, a switch occurs when the current online redo log file is full and writing must continue. However, you can configure log switches to occur at regular intervals, regardless of whether the current online redo log file is filled, and force log switches manually.
The database assigns each file a new log sequence number when a log switches and log writers begins writing to it. When the database reuses an online redo log file, this file receives the next available log sequence number. Filled online redo log files are available for reuse depending on the archiving mode:
■If archiving is disabled, which means that the database is in NO ARCHIVE LOG mode, then a filled online redo log file is available after the changes recorded in it have been check pointed (written) to disk by database writer (DBWn).
■If archiving is enabled, which means that the database is in ARCHIVE LOG mode, then a filled online redo log file is available to log writer after the changes have been written to the data files and the file has been archived.
Structure of the Online Redo Log
Online redo log files contain redo records. A redo record is made up of a group of change vectors, each of which describes a change to a data block. For example, an update to a salary in the employees table generates a redo record that describes changes to the data segment block for the table, the undo segment data block, and the transaction table of the undo segments.
The redo records have all relevant metadata for the change, including the following:
■SCN and time stamp of the change
■Transaction ID of the transaction that generated the change
■SCN and time stamp when the transaction committed (if it committed)
■Type of operation that made the change
■Name and type of the modified data segment
Multiple Copies of Online Redo Log Files
Oracle Database can automatically maintain two or more identical copies of the online redo log in separate locations. An online redo log group consists of an online redo log file and its redundant copies. Each identical copy is a member of the online redo log group. Each group is defined by a number, such as group 1, group 2, and so on. Maintaining multiple members of an online redo log group protects against the loss of the redo log. Ideally, the locations of the members should be on separate disks so that the failure of one disk does not cause the loss of the entire online redo log.