Why Oracle Uses Redo Logs

Every change you make to database blocks is first recorded as redo. Oracle implements write-ahead logging (WAL): before modified blocks are written to datafiles, the change description (redo) is flushed to the online redo logs. WAL guarantees that, after a crash, Oracle can replay committed work even if dirty buffers never reached the datafiles.

• Crash recovery: Reapply committed changes that were in memory but not yet on disk.
• Media/point-in-time recovery: With ARCHIVELOG mode, archived redo plus backups allow you to recover to a specific SCN/time.

1. Throughput: LGWR writes redo sequentially, which is faster and avoids random I/O.
2. Batching: Dirty buffers are written in batches by DBWR; not per-row.
3. Minimal redo size: Only the change vectors are logged, not entire blocks.

Oracle’s database buffer cache^[1] keeps active blocks in memory to reduce reads and to batch writes efficiently.

Online redo logs are organized into groups; each group may have multiple members (multiplexed copies on different disks). Oracle writes to one group at a time. When a group fills, a log switch occurs and the sequence number increments.

Tip: Multiplex each group (≥2 members on different devices) to guard against single-file loss.

Current group, size, members, and status:

SELECT l.group#, l.sequence#, l.bytes/1024/1024 AS size_mb,
       l.members, l.archived, l.status
FROM   v$log l
ORDER  BY l.group#;

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

Recent switches (useful for sizing and workload patterns):

SELECT sequence#, first_time, next_time
FROM   v$log_history
ORDER  BY first_time DESC FETCH FIRST 20 ROWS ONLY;

Force a log switch and archive (as needed):

ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM ARCHIVE LOG CURRENT;

[1] Database buffer cache: A shared memory area holding recently used blocks to minimize physical reads and allow efficient batched writes.