Oracle redo generation rate: capacity planning for archiving and Data Guard

Redo generation rate is the single most important capacity signal on the Oracle write path. It measures, in bytes per second, how fast change vectors are produced, and therefore how fast every downstream consumer must drain them: online redo logs, the archiver, Data Guard redo transport, and archive log storage.

Unlike log file sync wait time, which tells you commits are already slow, redo generation rate is a planning signal. A database generating 50 MB/s of redo needs redo log groups sized for that rate, an archiver that can sustain it, a Data Guard network link that can carry it, and archive storage that can absorb it. If any consumer falls behind the rate, redo backs up until the database hangs.

The signal comes from V$SYSSTAT, statistic redo size, a cumulative counter of redo bytes generated since instance startup. Derive a rate by sampling twice and computing the delta:

-- Sample redo generation rate (run twice, N seconds apart)
SELECT VALUE FROM V$SYSSTAT WHERE NAME = 'redo size';
-- bytes_per_sec = (value_t2 - value_t1) / seconds_between_samples

What this rate tells you depends on what it exceeds:

Each of these is a cliff-edge failure. Online redo log groups provide minutes to hours of buffer; archive destination free space provides hours to days. Once exhausted, there is no graceful degradation.

How the redo path works

Every data change generates a redo vector (for crash and media recovery) and an undo record (for rollback and read consistency). The redo vector enters the redo log buffer, a circular in-memory region in the SGA. On COMMIT, LGWR flushes the buffer to the current online redo log group. When that group fills, a log switch occurs: LGWR moves to the next group, and ARCn copies the filled group to the archive destination.

The downstream paths branch at the online redo log:

flowchart LR
  DML[DML changes] --> RB[Redo Log Buffer]
  RB -->|LGWR flush on COMMIT| ORL[Online Redo Logs]
  ORL -->|ARCn copy on switch| ARCH[Archive Destination]
  ORL -->|LNS or NSS transport| SRL[Standby Redo Logs]
  ARCH --> STORE[Archive Storage]
  SRL --> MRP[Managed Recovery Process]

Redo generation rate governs how fast data flows through every node in this graph. If any node cannot sustain the rate, redo backs up and the system degrades or hangs.

To measure peak rate more precisely than point sampling allows, use V$ARCHIVED_LOG to compute MB/s per archived log:

-- Peak redo rate per archived log (adjust dest_id and date range)
SELECT thread#, sequence#,
       blocks * block_size / 1048576 AS mb,
       (next_time - first_time) * 86400 AS seconds,
       ROUND((blocks * block_size / 1048576) /
             NULLIF((next_time - first_time) * 86400, 0), 2) AS mb_per_sec
FROM V$ARCHIVED_LOG
WHERE first_time BETWEEN SYSDATE - 7 AND SYSDATE
  AND dest_id = 1
  AND (next_time - first_time) * 86400 > 0
ORDER BY mb_per_sec DESC;

This reveals the per-log-switch peak rate. Short spikes that V$SYSSTAT delta sampling might miss show up as small, fast-switching archive logs.

What inflates redo volume above baseline

Several configuration choices and workload patterns push redo rate above what raw DML volume would suggest.

Supplemental logging (GoldenGate, Logminr, CDC tools). Minimal supplemental logging adds little overhead. But all-column or primary-key supplemental logging, which CDC tools like GoldenGate require, increases redo volume by 2 to 5x. The exact multiplier is workload-dependent. The only reliable way to know your overhead is to measure redo size before and after enabling the supplemental logging level you plan to use.

Force logging. ALTER DATABASE FORCE LOGGING ensures all operations generate redo, including those that would normally use NOLOGGING (direct-path loads, certain DDL). This is required for Data Guard standby correctness. On workloads with significant bulk-load activity, force logging can substantially increase redo volume.

Bulk DML and index maintenance. Large UPDATE or DELETE statements generate redo proportional to the number of blocks modified. Index maintenance on bulk inserts adds redo for leaf block splits. A bulk load with indexes generates more redo than the same load without.

NOLOGGING operations. Direct-path inserts, CREATE TABLE AS SELECT with NOLOGGING, and certain index builds generate minimal redo. This reduces redo rate but leaves the affected blocks unrecoverable until the next backup. On a Data Guard standby, NOLOGGING blocks appear as corrupt (ORA-01578 with ORA-26040) after failover. Force logging prevents this at the cost of higher redo volume.

Sizing the downstream paths

Online redo log groups

The MAA (Maximum Availability Architecture) guidelines for redo log group size, based on peak redo rate, are:

Add 30% headroom to your measured peak rate before consulting the table. For example, if your peak is 18 MB/sec, use 23.4 MB/sec, which falls in the 25 MB/sec tier (16 GB groups).

Log switch frequency is the operational signal that confirms sizing. Properly sized redo logs should switch no more than 4 to 6 times per hour during peak load. Switches more frequent than once per minute almost guarantee checkpoint not complete messages and write-path stalls.

Check switch frequency:

-- Redo log switches per hour over the last day
SELECT TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24') AS hour,
       COUNT(*) AS switches
FROM V$LOG_HISTORY
WHERE FIRST_TIME > SYSDATE - 1
GROUP BY TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24')
ORDER BY 1;

Archiver throughput

The archiver must drain redo faster than the long-term average rate produces it, with enough headroom to catch up after peaks. If average redo rate is X and peaks hit 2X for short windows, the archiver needs sustained throughput above X to drain the backlog during valleys. If the archive destination is on slower storage than the online redo logs, the archiver can become the bottleneck even when redo log I/O is fine.

Check archiver status:

-- Archiver process state
SELECT PROCESS, STATUS FROM V$ARCHIVE_PROCESSES;
-- STATUS should be IDLE or BUSY, not STOPPED

Also monitor redo log space requests in V$SYSSTAT. Non-zero values mean sessions are waiting for redo log buffer space, which indicates LGWR or redo log sizing problems.

Data Guard redo transport

For Data Guard, redo generation rate determines the minimum network bandwidth between primary and standby, and the minimum LOG_BUFFER size.

Network bandwidth. The inter-site link must sustain your peak redo rate with headroom. Oracle MAA recommends sizing TCP send and receive socket buffers to 3x the bandwidth-delay product (BDP) of the network link. A link that can barely sustain average redo rate will develop transport lag during peaks.

LOG_BUFFER. For Data Guard configurations using ASYNC redo transport with high redo generation rates, Oracle recommends a minimum LOG_BUFFER of 256 MB. The redo log buffer is where the transport process reads redo for shipping; an undersized buffer increases transport latency under high redo rates.

Standby redo logs. Standby redo log groups should be the same size as online redo log groups. The number of standby redo log groups per thread should be the number of online redo log groups plus one.

Redo transport compression. The COMPRESSION attribute on the LOG_ARCHIVE_DEST_n parameter compresses redo before WAN transmission. This requires the Advanced Compression option license. It reduces bandwidth requirements but adds CPU overhead on the primary.

Archive storage burn rate

Archive storage consumption is a direct function of redo generation rate. At 10 MB/sec sustained, that is approximately 843 GB per day of archive logs.

The archive destination should hold at least 24 hours of archive logs at peak generation rate, after accounting for backup and deletion cycles. Monitor FRA space:

-- FRA space utilization
SELECT NAME,
       SPACE_LIMIT / 1048576 AS limit_mb,
       SPACE_USED / 1048576 AS used_mb,
       SPACE_RECLAIMABLE / 1048576 AS reclaimable_mb
FROM V$RECOVERY_FILE_DEST;

Runway estimation

When redo generation rate exceeds archive throughput or Data Guard transport bandwidth, you have finite runway before the database hangs:

time_to_hang = online_redo_log_space_available_for_reuse /
               (redo_generation_rate - archive_throughput)

If archive throughput exceeds redo rate, runway is effectively infinite. If redo rate exceeds archive throughput, compute the time and set an alert. The online redo log groups (typically 3 to 5) provide the initial buffer, but once all are full and unarchived, the hang is immediate: LGWR cannot switch to a new group and every COMMIT blocks.

Signals to watch in production

How Netdata helps

Netdata collects Oracle metrics at per-second granularity, which matters for redo capacity planning because batch-driven redo spikes can be 10x the average rate for short windows that 5-minute polling misses entirely.

• Redo generation rate as a continuous per-second rate. Delta computation of redo size shows spikes that coarse polling intervals hide.
• Correlation between redo rate and log file sync. When both rise together, the bottleneck is redo I/O throughput. When redo rate spikes but log file sync stays flat, the redo path has headroom.
• Archive destination fill rate alongside Data Guard transport lag on the same timeline. This lets you distinguish a network bandwidth problem from an archive storage problem in seconds.
• Anomaly flags on slowly rising redo rate. A gradual increase from data growth, supplemental logging changes, or new CDC consumers surfaces as an anomaly before it crosses a static threshold.

See Oracle Database monitoring with Netdata for the full metric set.

Related guides

• How Oracle Database actually works in production: a mental model for operators
• Oracle ’log file sync’ waits: slow commits, LGWR, and the redo path
• Oracle Database monitoring checklist: the signals every production instance needs
• Oracle Database monitoring maturity model: from survival to expert
• Oracle slow commit cascade: when redo storage degrades and every transaction waits