Oracle DBA · Lesson 13A

Oracle DBA Lesson 13A — Follow an Online Redo Group Through Reuse

Online redo groups rotate in a circle. LGWR fills CURRENT, a log switch moves on, and a group is reused only when both the archive gate and the recovery gate are clear — previous is not the same as ready.

Watch on YouTube

AI Ops Pro

Circular reuse, not “old means free”

A typical database has a small set of online redo groups. LGWR writes into the group marked CURRENT. When that group fills (or you force a log switch), LGWR moves to the next group. The path is circular: Group 1 → Group 2 → Group 3 → back to Group 1.

PREVIOUS ≠ READY — a group that was used earlier is not automatically free to overwrite.
LGWR moves on only when the next group can accept redo.
Status moves through a lifecycle you will see in v$log: CURRENT → ACTIVE → INACTIVE (with UNUSED for a group that has not yet been written).

Group identity stays; sequence advances

On each rotation the physical group number stays the same. What advances is the log sequence number for that fill of the group.

GROUP# = physical identity of the online redo group (and its members).
SEQUENCE# = this rotation’s fill of that group.

A log switch hands LGWR the next ready group and bumps sequence for the new CURRENT fill. Thinking “we reused Group 2” without checking sequence and status is how people misread v$log.

Lifecycle status describes recovery need

Status is not decoration — it tells you whether that redo is still required for instance recovery:

CURRENT — receiving redo right now. Not a reuse candidate.
ACTIVE — no longer CURRENT, but still needed for instance recovery (checkpoint progress has not cleared it yet).
INACTIVE — recovery need for that fill has passed (for the instance-recovery gate).
UNUSED — not yet written. Unused is not an archive failure; it simply has not held redo yet.

CURRENT is never an “old reuse candidate.” You overwrite a group only after it is eligible — never while it is CURRENT.

Reuse requires two independent gates

Before LGWR can reuse a group, both gates must be satisfied:

Archive gate (in ARCHIVELOG mode) — configured archive destinations have accepted a copy of that completed log (ARCHIVED = YES).
Recovery gate — checkpoint progress has finished with the redo in that group, so status is no longer ACTIVE for recovery need.

Both gates before reuse. Archiving alone does not clear an ACTIVE group. Clearing recovery need alone does not satisfy ARCHIVELOG’s archival requirement.

Members are copies inside one group

Multiplexed members sit inside the same group — same redo, mirrored files — not extra groups and not extra sequences. Example shape:

REDO GROUP 2 → MEMBER A /redo1/group2.log and MEMBER B /redo2/group2.log (same redo).

On healthy members, v$logfile.status is often blank. Member problems show up there; group lifecycle status lives in v$log.

Read group state and member paths together

Group lifecycle and archived flag:

SELECT group#, thread#, sequence#, members, archived, status
FROM   v$log
ORDER  BY group#;

Member paths (and member-level status):

SELECT group#, member, status
FROM   v$logfile
ORDER  BY group#, member;

Read GROUP# + THREAD# + SEQUENCE# with ARCHIVED and STATUS from v$log, then join the picture to member paths via GROUP# in v$logfile.

Gotchas

Previous ≠ ready. Circular reuse waits on both gates.
ACTIVE + ARCHIVED = YES is still not automatically reusable — recovery need can still block overwrite.
UNUSED ≠ archive failure.
Members multiplex one group; they do not create extra sequences.
CURRENT receives redo; SEQUENCE# advances on each fill; STATUS tracks recovery need.

A working journal for Oracle DBAs.

Oracle Apps DBA