Contents

Online Redo LogEdit

This article provides a neutral, technical overview of the Online Redo Log as it appears in modern relational database systems. It explains what the component does, how it is structured, and how it fits into the broader topics of durability, crash recovery, and data protection. Throughout, terms that would normally link to other encyclopedia articles are presented as term or term human readable here to aid navigation.

Overview

  • The Online Redo Log is a core mechanism that records a sequential history of all changes made to the database’s data files. Its primary purpose is to guarantee durability: once a transaction is committed, the associated redo records ensure the change can be recovered even if a failure occurs before the data files are updated on disk.
  • In many systems, the online redo log is complemented by an Archived Redo Log, which stores a persistent history of redo records once a log group is closed and archived. This archive enables point-in-time recovery and media recovery scenarios. See Archived Log for more on this distinction.
  • The redo log is typically managed by a dedicated background process (often referred to as the log writer) that coordinates writes to the online redo log files. In Oracle‑style terminology, this involves the LGWR process writing redo entries from the shared memory area known as the Redo Log Buffer to physical log files.
  • The contents of the online redo log reflect the sequence of data changes, and each redo entry is associated with a monotonically increasing identifier such as a SCN to establish a global order of operations across the system.

Architecture and Operation

  • Structure of online redo logs: A database instance maintains one or more log groups, each containing one or more log members. The members of a single log group are copies of the same redo sequence stored on separate physical devices to guard against single-disk failures. When one log group fills, the instance switches to the next group in the cycle (a log file switch) and, if configured, archives the full group to create the archived trail. See Redo Log for the general concept and LGWR for the process that coordinates writes.
  • Redo log buffer and write path: Changes to data blocks are first recorded in a memory area known as the Redo Log Buffer. The LGWR process periodically flushes this buffer to the current online redo log group. The commit operation is typically a trigger for an immediate write, ensuring durability before the transaction is reported as committed to the user.
  • Multiplexing and redundancy: To protect against media failure, many deployments multiplex online redo logs by maintaining multiple identical members for each log group across separate disks. This design reduces the risk that a single disk fault will render redo information unavailable for recovery. See Redo Log Multiplexing for related discussions of redundancy strategies.
  • Archiving and retention: When a log group fills, the mechanism may archive the group to an archived redo log file, creating a durable record for use in recovery scenarios. Archived logs can be applied to data files during media recovery or point-in-time recovery. See Archived Log for more on archiving behavior and practices.

Role in Recovery and Durability

  • Instance recovery: If the database instance terminates abnormally, upon restart the system uses the online redo logs to redo committed transactions that may not have been fully written to data files yet. This crash recovery step ensures that the committed state is preserved. The logical ordering is anchored by the SCN associated with each redo entry.
  • Media and point-in-time recovery: When data loss affects storage, administrators can restore from backups and then use the Archived Log entries to reapply changes up to a desired point in time. This capability hinges on the availability and integrity of the archived redo logs.
  • Relationship to undo and data blocks: The redo log records changes that would be redone during recovery, while other structures such as the Undo mechanism help with rollback operations and consistent read views. Together, these components deliver atomic, durable transactions in the presence of failures.
  • Consistency and checkpoints: A checkpoint produces a known safe point in the data files, aligning the data block writes with the redo history. This coordination reduces recovery time and helps ensure that the most recent committed state is recoverable with minimal redo work. See Checkpoint for related concepts.

Sizing, Maintenance, and Best Practices

  • Number and size of log groups: The typical design emphasizes multiple log groups with adequately sized members to balance the frequency of log switches against the risk of running out of space during heavy activity. Too-small groups can cause frequent log switches and archiving overhead; too-large groups can slow recovery because there are larger units to archive and manage. See Redo Log for general considerations of log behavior.
  • Archiving mode and durability requirements: Enabling ARCHIVELOG mode (where archiving is active) increases protection against data loss but incurs additional storage and I/O requirements. In environments with strict recovery objectives, this mode is often favored; in more constrained settings, NOARCHIVELOG mode may be used with limited recovery options. See Archived Log for related trade-offs.
  • Redundancy and hardware layout: Multiplexed redo logs across separate disks provide resilience against disk failures. However, there are cost and performance considerations, such as the impact of parallel I/O and the need to ensure consistent synchronization across members. See Redo Log Multiplexing and LGWR for operational specifics.
  • Monitoring and maintenance tasks: Regular checks of log space usage, archive destinations, and backup/restore pipelines help avoid situations where a failed archival process or an out-of-space condition could compromise recoverability. Administrators may also review log file switch frequency as an indicator of workload characteristics.

Controversies and Debates (Practical Perspectives)

  • Archiving strategy vs operational cost: Proponents of aggressive archiving emphasize maximum recoverability and regulatory compliance, while others argue for leaner configurations where the focus is on performance and storage efficiency. The right balance depends on risk tolerance, backup windows, and available infrastructure.
  • Log file sizing versus recovery speed: Smaller log groups can improve failure isolation and speed up certain maintenance tasks but may increase the frequency of log switches and archiving I/O. Larger groups reduce switch activity but can lengthen recovery times if a large amount of redo must be processed. Different environments prioritize different trade-offs based on workload characteristics.
  • Reliability through redundancy vs simplification: Multiplexing online redo logs enhances protection but adds complexity and potential synchronization challenges. Some shops favor simpler architectures with robust backup and archiving strategies, while others deploy comprehensive redundancy to minimize single points of failure.
  • ARCHIVELOG mode versus operational simplicity: ARCHIVELOG mode offers superior recoverability at the cost of additional management overhead, storage, and potential performance considerations under heavy archiving load. In contrast, NOARCHIVELOG mode simplifies operations but imposes stricter recovery limitations.

See also