Oracle Redo Logs

One of the foremost features of Oracle is its ability to recover data after a disk failure. Whenever a failure occurs, the DBA can direct Oracle to use the redo logs to apply after-images of all database changes. When an Oracle database is rolled-forward, the redo logs are used to apply the row after-images to the database.
The following series of images will show you how redo logs travel through several stages on their way to the archived redo log file system.

In the context of Oracle RDBMS, redo logs function as transaction journals that record all changes made to the data in the database. Here's a detailed explanation of their role and significance:
What Are Redo Logs?

• Definition: Redo logs are files that contain a complete record of all changes made to the data in the database as a result of transactions. This includes inserts, updates, deletes, and any structural changes, like table alterations.
• Purpose: The primary purpose of redo logs is to provide a mechanism for data recovery. In the event of a system failure, redo logs ensure that all committed transactions can be reconstructed and no data loss occurs.

Why Are Redo Logs Considered Transaction Journals?

• Transactional Changes: Similar to how a journal records a detailed log of events, redo logs chronologically capture every data modification made within the database. This includes both user transactions (e.g., updates to a table) and internal database operations.
• Data Persistence: Even if the changes are not immediately written to the data files on disk, redo logs capture these modifications. The database writes these entries to the redo log files as soon as a transaction is initiated, ensuring data integrity.
• Commit and Recovery: When a transaction is committed, the changes are guaranteed to be recorded in the redo logs. In case of an unexpected failure, the Oracle RDBMS uses these logs to replay the transactions, thereby restoring the database to a consistent state.

How Redo Logs Work in Oracle

1. Writing to Redo Logs: As changes are made in the database, Oracle writes redo entries to the redo log buffer in memory. These entries are then flushed to the redo log files on disk at regular intervals or when a transaction is committed.
2. Redo Log Buffer: This is a memory area where redo data is temporarily stored before being written to disk. It ensures that changes are recorded quickly and efficiently.
3. Log Writer (LGWR): The Oracle background process responsible for writing the contents of the redo log buffer to the redo log files. This happens when:
   • A transaction is committed.
   • The redo log buffer is one-third full.
   • A time threshold (like every 3 seconds) is reached.
   • The database undergoes a checkpoint.

Transaction Journaling for Recovery

• Crash Recovery: If a database crashes or is shut down abnormally, Oracle uses the redo logs to replay changes that were committed but not yet written to the data files. This ensures that no committed data is lost.
• Media Recovery: If data files are lost or corrupted, Oracle can restore them from a backup and then use the redo logs to apply all changes made since the backup, thus recovering the database to its most recent committed state.

Summary

• Redo logs act as transaction journals by recording every change made to the database in the order they occur.
• This journaling ensures that all committed transactions are preserved, allowing Oracle to recover from crashes or failures and maintain data consistency.
• Redo logs are essential for protecting the integrity of the database, making them a cornerstone of Oracle's robust recovery mechanism.

By functioning as transaction journals, redo logs provide an efficient way to safeguard data, making sure that no committed changes are lost and that the database can be quickly recovered to its correct state in case of an unexpected issue.

• Redo logs are transaction journals and each transaction is recorded in the redo logs. Redo logs are used in a serial fashion with each transaction queuing up in the redo log buffers and being written one at a time into the redo logs. Redo logs should switch about every thirty minutes. However, you may need to adjust the time up or down depending on how important your data is. The rule of thumb is to size the redo logs such that you only loose the amount of data you can stand to loose should for some reason the online redo log become corrupt. With modern Oracle redo log mirroring and with disk array mirroring^[1] and various forms of online disk repair and replacement the occurrence of redo log corruptions has dropped to practically zero, so size based on the number of archive logs you want to apply should the database fail just before your next backup.
  The LOG_BUFFER_SIZE and LOG_BUFFERS parameters control the redo log buffers. The LOG_BUFFER_SIZE should be set to reduce the number of writes required per redo log but not be so large that it results in an excessive IO wait time. Some studies have shown that sizing bigger than one megabyte rarely results in performance gains. Generally I size the LOG_BUFFER_SIZE such that it is equal to or results in an even divisor of the redo log size. Monitor redo logs using the alert log, V$LOGHIST, V$LOGFILE, V$RECOVERY_LOG and V$LOG DPTs.

There are several Oracle processes that assist with processing redo logs. These include:

ARCOMON or Archive monitor process	This is a process on UNIX that monitors the archive process and writes the redo logs to the archives.
ARCH or Archiver Process	This process is only active if archive logging is in effect. This process writes the redo log data files that are filled into the archive log data files.
LGWR or Log Writer process	This process transfers data from the redo log buffers to the redo log database files.

Now that we have reviewed the basics, let us move on to look at the performance and tuning implications of the redo logs.
The following section discusses more about the redo log function.

The operations are executed in the following order.

1. The redo entries are written to the redo log buffer. When a transaction issues a COMMIT or reaches a normal end of task, the entries are written to the online redo log files.
2. The LGWR process takes the images from the log buffer and places them into the online redo log files.
3. When Oracle switches redo log files, the old redo log file is copied to an archived redo log file system by the ARC0 process. The redo log file can then be overwritten by Oracle.
4. As the archived redo log file system becomes full, a user-written process is invoked to copy the redo log files to tape for long-term storage.

• Determining the Global Database Name
  The global database name consists of the user-specified local database name and the location of the database within a network structure. The DB_NAME initialization parameter determines the local name component of the database name, and the DB_DOMAIN parameter, which is optional, indicates the domain (logical location) within a network structure. The combination of the settings for these two parameters must form a database name that is unique within a network.For example, to create a database with a global database name of test.us.acme.com, edit the parameters of the new parameter file as follows:
  

  DB_NAME = test
  DB_DOMAIN = us.ooportal.com
  DB_DOMAIN = us.ooportal.com
  

  
  You can rename the GLOBAL_NAME of your database using the ALTER DATABASE RENAME GLOBAL_NAME statement. However, you must also shut down and restart the database after first changing the DB_NAME and DB_DOMAIN initialization parameters and recreating the control files. Recreating the control files is easily accomplished with the command ALTER DATABASE BACKUP CONTROLFILE TO TRACE.
• DB_NAME Initialization Parameter
  DB_NAME must be set to a text string of no more than eight characters. During database creation, the name provided for DB_NAME is recorded in the datafiles, redo log files, and control file of the database. If during database instance startup the value of the DB_NAME parameter (in the parameter file) and the database name in the control file are not the same, the database does not start.

[1] disk array mirroring : Disk array mirroring is a technique for data redundancy where data is synchronously written to two or more physical disks within a disk array. When used with Oracle redo log mirroring, it provides an additional layer of protection for the redo log files, which are crucial for database recovery. This ensures that even if one disk fails, the redo log data remains available on the mirrored disk, allowing for uninterrupted database operation and recovery.