Lesson 8

Managing Oracle Database Redo Logs: Module Conclusion

Online redo is the recovery record that connects ordinary database work with Oracle Database durability. Every change generates redo entries, LGWR writes those entries to the current online redo log group, and Oracle cycles through the configured groups as each sequence closes. The structures look simple, but dependable administration requires several connected skills: protecting members, identifying group state, adding capacity, removing obsolete files, relocating storage, and controlling a switch without weakening recovery.

This module developed those skills as one operational workflow. A decision made in one lesson affects the others. Multiplexing determines whether a member can fail without stopping redo. Group status determines whether maintenance is safe. Log size affects switch frequency. Archive destination health determines whether groups can be reused in ARCHIVELOG mode. A final review should therefore emphasize relationships and decision gates, not merely repeat individual commands.

The Recovery Chain You Are Protecting

A committed transaction is acknowledged only after the necessary redo reaches the online log, even though modified data blocks may remain in memory. If an instance stops unexpectedly, Oracle uses online redo and undo during automatic instance recovery to reconstruct committed work and reverse incomplete transactions. This recovery does not normally require an administrator to restore a datafile from backup.

Media recovery solves a different problem. When a datafile is lost or damaged, an administrator restores an appropriate backup and applies subsequent redo to roll that restored file forward. Archived redo extends the recoverable history beyond the finite online groups. Online redo, archived redo, backups, control-file metadata, and tested recovery procedures therefore form a chain. A weakness anywhere in that chain can limit the database's recovery point.

The online log is divided into groups. Oracle writes to one group at a time for each redo thread. A group can contain multiple members, and LGWR writes the same redo to every valid member. Members provide redundancy within the group; groups provide the reusable sequence through which Oracle cycles. Confusing a group with a member is one of the most common causes of unsafe maintenance.

Lesson 1: Understand the Redo Architecture

The module began by establishing the role of online redo in recovery. Redo records describe changes needed to reproduce database work. They are not copies of entire data blocks, and they are not a substitute for database backups. The redo log buffer temporarily holds generated records in memory, while LGWR writes them to disk according to Oracle's write rules.

Each enabled redo thread needs multiple groups so Oracle can write one sequence while earlier sequences progress through checkpoint and archive processing. In a single-instance database, one thread is typical. Oracle RAC assigns threads to instances, so a DBA must interpret a group number together with its thread. A group that is current for one thread tells nothing about the current group for another.

Log sequence numbers identify successive redo ranges within a thread. They let administrators correlate an online group with archived copies, backup metadata, and Data Guard transport. Sequence alone is not globally unique in every context; thread and database incarnation also matter. This architecture explains why every later operation begins with inspection rather than assumption.

Lesson 2: Protect Redo Through Multiplexing

Multiplexing places two or more members in a group, preferably on independent storage failure domains. Because members contain identical redo, Oracle can continue using the group when one member becomes unavailable, provided another valid member remains. Multiplexing protects against a member or storage-path failure; it does not replace backups, archived logs, storage redundancy, Data Guard, or recovery testing.

A sound design avoids placing every member behind the same controller, mount point, or administrative failure. Two filenames on one vulnerable device do not provide meaningful separation. Apply a consistent member count to every group, use clear naming, monitor all member statuses, and document whether Oracle Managed Files, ASM, or conventional filesystem storage owns each file.

When a member reports INVALID or STALE, investigate the storage and alert log promptly. A null member status in V$LOGFILE normally means the member is in use; null is not itself an error. Redundancy buys time to correct a failure, but leaving a degraded group in service consumes that safety margin.

Lesson 3: Inspect Before You Change

The central inspection joins group information from V$LOG with member information from V$LOGFILE:

SELECT l.thread#,
       l.group#,
       l.sequence#,
       l.bytes / 1024 / 1024 AS size_mb,
       l.members,
       l.archived,
       l.status AS group_status,
       f.status AS member_status,
       f.member
FROM   v$log l
JOIN   v$logfile f ON f.group# = l.group#
ORDER  BY l.thread#, l.group#, f.member;

CURRENT identifies the group receiving redo. ACTIVE identifies a previous group still required for instance recovery. INACTIVE means it is no longer required for instance recovery, although archive or media-recovery requirements can remain. UNUSED often identifies a newly created group that has never received redo. The ARCHIVED column is a separate condition, not another spelling of group status.

A complete baseline records group sizes, member counts, paths, threads, sequences, archive state, and switch history. It also checks the alert log and archive destinations. Capture this evidence before and after every structural change. The comparison proves what changed and makes rollback decisions defensible.

Lesson 4: Create Groups and Members Deliberately

Adding a group increases the number of redo containers in a thread. Adding a member increases redundancy inside an existing group. Choose the operation that matches the requirement. A new group should follow the established size and multiplexing design unless you are performing a planned migration.

ALTER DATABASE ADD LOGFILE GROUP 4
  ('/redo1/oradata/ORCL/redo04a.log',
   '/redo2/oradata/ORCL/redo04b.log')
  SIZE 1G;

To improve an existing group's redundancy, add a member with a fully qualified path:

ALTER DATABASE ADD LOGFILE MEMBER
  '/redo2/oradata/ORCL/redo01b.log'
  TO GROUP 1;

Oracle Managed Files can create names and place files according to configured destinations, reducing manual path management. Conventional filesystem files require explicit paths and operating-system planning. In RAC, specify and verify the intended thread. After creation, query the dynamic performance views and confirm that every new member is accessible before depending on it or removing older storage.

Lesson 5: Drop Only After the Safety Gate Passes

Dropping a group and dropping a member are different structural operations. A group must not be current, must be safely reusable, and must be archived first when archiving is required. Oracle also requires enough groups to remain for the thread. If the target is CURRENT or ACTIVE, switch under control and wait; one switch does not promise immediate inactivity.

ALTER DATABASE DROP LOGFILE GROUP 3;

A member can be dropped only when Oracle's state restrictions are satisfied and another valid member remains in the group. Use its full server-side filename:

ALTER DATABASE DROP LOGFILE MEMBER
  '/oldredo/oradata/ORCL/redo01a.log';

For conventional filesystem storage, these statements remove control-file references but do not necessarily delete the operating-system files. Verify the database change first, then remove obsolete files according to the storage procedure. Oracle Managed Files are managed by Oracle and must not be manipulated casually with operating-system commands. CLEAR LOGFILE is a recovery-oriented operation, not a convenient synonym for dropping a normal group.

Lesson 6: Relocate With an Offline or Online Plan

An offline relocation preserves existing groups while changing member paths. Shut down normally, move or copy the conventional filesystem members, mount the database, update control-file names, and then open:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

ALTER DATABASE
  RENAME FILE '/oldredo/oradata/ORCL/redo01a.log'
           TO '/newredo/oradata/ORCL/redo01a.log';

ALTER DATABASE OPEN;

ALTER DATABASE RENAME FILE changes the path stored in the control file. It does not move the operating-system file. The destination file must already exist, and every affected member must be accounted for. After opening, verify paths, perform monitored switches, review the alert log, and back up the control file.

An online relocation is an add, switch, verify, and drop replacement. Add a correctly sized, multiplexed group or a replacement member at the destination. Confirm it is usable. Allow the old group to become inactive and archived when required, then drop the old configuration. Delete old conventional files only after verification. The online approach preserves availability but does not relax any drop condition.

Lesson 7: Switch With a Defined Purpose

Oracle switches automatically when the current group fills. A DBA can request a switch for planned maintenance, archive-path validation, or another approved operational boundary:

ALTER SYSTEM SWITCH LOGFILE;

The command advances the connected instance's redo thread. It does not prove that the previous group is already inactive, every destination archived the sequence, or every standby applied it. Verify the new current group and sequence in V$LOG, check history and archived-log records, and examine Data Guard status where applicable.

A switch is not the same as ALTER SYSTEM CHECKPOINT. A checkpoint advances recovery-related datafile writes; a switch changes the current redo group. ALTER SYSTEM ARCHIVE LOG CURRENT serves an archive-oriented objective and, in RAC, covers enabled threads, whereas SWITCH LOGFILE applies to the current instance's thread. Repeated unnecessary switches can create small archives and increase checkpoint, archiver, storage, and transport pressure.

Archived Redo Extends the Recovery Window

In ARCHIVELOG mode, Oracle copies filled online redo groups to one or more archive destinations before those groups are reused. An archived redo log retains the sequence and redo range from a filled online group. If a multiplexed group has healthy identical members, the archiver needs a readable member to create the archived copy; it does not archive every member as a separate logical sequence.

Archived logs support media recovery, standby databases, LogMiner analysis, and other operations that need historical redo. They also consume storage and require a lifecycle policy. Monitor destination validity and capacity, back up archived logs with RMAN, and delete them only through a retention and recovery policy that accounts for backups and standby apply. Filesystem cleanup performed outside that policy can create a recovery gap even when the database itself remains open.

Use V$ARCHIVE_DEST to inspect destination state and V$ARCHIVED_LOG to interpret archived copies. Multiple records can exist for one thread and sequence because the log was archived to different destinations, copied, restored, or cataloged. The APPLIED column is meaningful for appropriate standby records; a local row showing NO does not by itself indicate failure.

Recovery Terms That Must Remain Distinct

Instance recovery is Oracle's automatic response when an instance fails while database files remain available. Oracle rolls forward with redo and then uses undo to resolve uncommitted work. In RAC, a surviving instance can perform recovery for a failed instance.

Media recovery is required when a datafile or another protected database file must be restored or repaired. A DBA normally uses RMAN to restore backups and apply archived and online redo. Complete recovery applies all available required redo. Point-in-time recovery deliberately stops at an earlier SCN, time, or sequence and has additional incarnation and opening requirements.

Flashback is a family of features for reversing certain logical or physical changes using flashback data and undo-related mechanisms. It does not eliminate backup, redo, or media-recovery planning. Select the recovery method according to the failure, available evidence, recovery point objective, and approved runbook.

A Unified Redo Administration Runbook

Define the outcome. Decide whether the task changes redundancy, capacity, paths, group count, member count, or the current sequence.
Confirm recoverability. Check backups, ARCHIVELOG policy, archive destinations, Data Guard health, and control-file protection appropriate to the risk.
Capture the baseline. Record groups, threads, sequences, sizes, members, paths, group status, member status, and archive state.
Check scope. Account for ASM or OMF ownership, conventional filesystems, RAC threads, standby redo, and shared-storage visibility.
Add before subtracting. When replacing capacity or redundancy online, create and verify the new group or member before removing the old one.
Respect state gates. Never treat CURRENT, ACTIVE, INACTIVE, and ARCHIVED as interchangeable conditions.
Issue the smallest correct command. Distinguish group operations, member operations, switches, checkpoints, and archive-current requests.
Verify immediately. Re-query configuration, inspect the alert log, test the redo cycle when appropriate, and confirm archive or standby outcomes.
Clean up last. Remove obsolete conventional files only after control-file changes and operational checks pass.
Preserve evidence. Record commands, before-and-after results, backups, hashes, timestamps, and any deviations from the approved plan.

Final Knowledge Check

Before leaving this module, you should be able to explain why every database needs multiple groups, why production designs commonly multiplex members, and why members should occupy independent failure domains. You should be able to read V$LOG and V$LOGFILE without confusing group state, member state, archive state, or thread scope.

You should also be able to create a properly sized group, add a member, identify when a group or member can be dropped, choose between offline relocation and online replacement, and force one intentional switch. For every command, you should know what Oracle changes in the control file, what remains at the operating-system layer, which safety condition applies, and how to verify success.

Most importantly, redo administration is recovery administration. A syntactically successful command is not the final result. The final result is a configuration that continues recording redo, survives the intended failures, archives according to policy, supports standby transport where configured, and remains usable during a tested restore and recovery. Keep that outcome at the center of every maintenance decision.

Together, these practices turn redo maintenance from a collection of isolated commands into a repeatable recovery discipline that administrators can explain, audit, test, and improve continuously, safely.

The next module turns from online redo log management to archived redo log operations. You will build on this foundation by examining archive modes, destinations, processes, retention, and the role of archived sequences in recovery. The boundary is natural: Module 4 protected and controlled the reusable online redo cycle; Module 5 follows completed redo beyond that cycle and manages it as durable recovery history.