Oracle Data Guard transport and apply lag: RPO, RTO, and gap detection

Data Guard lag is two measurements operators often treat as one. Transport lag is how far behind the standby is in receiving redo: your real-time Recovery Point Objective (RPO) exposure, the data you would lose if the primary failed right now. Apply lag is how far behind the standby is in applying that redo: your real-time Recovery Time Objective (RTO) exposure, the extra time the standby needs to finish catching up before it can open after a failover.

The distinction matters because the right response differs. Transport lag points at the network path, the primary redo generation rate, and whether SYNC or ASYNC transport is configured. Apply lag points at the standby I/O subsystem, the Managed Recovery Process (MRP0), and whether a redo gap is blocking apply. Alerting on “lag” without splitting these two signals leads to wrong responses at 3 a.m.

This guide covers reading V$DATAGUARD_STATS on the standby and V$ARCHIVE_DEST_STATUS on the primary, detecting redo gaps, and how SYNC transport and Maximum Protection mode turn standby health into primary health.

What transport lag and apply lag actually measure

Transport lag is the wall-clock time between the most recent redo generated on the primary and the most recent redo received at the standby. If the primary is at SCN 10,000 and the standby has only received up to SCN 9,990, transport lag is the time between those two points. On failover, redo generated but never transported is lost.

Apply lag is the wall-clock time between the most recent redo received at the standby and the most recent redo applied to the standby datafiles. Redo may be sitting in standby redo logs or archive logs, received but not yet recovered. On failover, the standby must finish applying this pending redo before it can open.

Typical playbook thresholds: transport lag beyond 1 minute warrants investigation, apply lag beyond 30 minutes is a TICKET, beyond 1 hour is a PAGE. Your thresholds should come from your declared RPO and RTO SLAs, not from generic defaults.

How Data Guard ships and applies redo

flowchart LR
    A["Primary DB\nLGWR writes redo"] --> B["Network transport\nLGWR ASYNC or SYNC"]
    B --> C["Standby: RFS\nreceives redo into\nstandby redo logs"]
    C --> D["MRP0\napplies redo\nto standby datafiles"]
    A -.->|"transport lag\nmeasured here"| C
    C -.->|"apply lag\nmeasured here"| D

On the primary, LGWR flushes redo from the redo log buffer to the online redo logs. For Data Guard, LGWR (or ARCn in ARCH-shipping configurations) ships redo to the standby. The RFS process on the standby receives the redo and writes it to standby redo logs or archive logs. MRP0 then reads those logs and applies redo to the standby datafiles, block by block, in the same way crash recovery applies redo during instance startup.

Transport lag is the gap between primary redo generation and RFS receipt. Apply lag is the gap between RFS receipt and MRP0 application.

Reading V$DATAGUARD_STATS on the standby

V$DATAGUARD_STATS is the canonical view for both lag measurements. It returns rows only when queried on the standby database. On the primary, it returns no rows.

-- Run on the standby database:
SELECT NAME, VALUE, DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag', 'apply lag', 'apply finish time');

The VALUE column is a VARCHAR2 formatted as an interval, for example +00 00:00:05 (0 days, 0 hours, 0 minutes, 5 seconds). Parse it carefully if you are feeding it into monitoring tooling. The NAME values you will see include:

The DATUM_TIME column records when the standby last received the data used to compute these metrics. This column is critical and frequently ignored.

The DATUM_TIME trap

Transport lag can report +00 00:00:00 (zero) even when the standby has stopped receiving redo entirely. The lag computation uses the last known data point. If the standby is disconnected from the primary, no new data arrives, and the computed lag stays frozen at whatever it was when the connection dropped.

The real health indicator is whether DATUM_TIME is advancing. If you query V$DATAGUARD_STATS twice, 30 seconds apart, and DATUM_TIME has not changed, the standby is not receiving redo regardless of what the VALUE column says. Monitoring only the lag value without checking DATUM_TIME staleness is a common blind spot that hides transport failures behind a zero.

Reading V$ARCHIVE_DEST_STATUS on the primary

From the primary side, V$ARCHIVE_DEST_STATUS gives a coarser view of standby progress:

-- Run on the primary database:
SELECT DEST_ID, STATUS, ARCHIVED_SEQ#, APPLIED_SEQ#,
       ARCHIVED_SEQ# - APPLIED_SEQ# AS lag_sequences
FROM V$ARCHIVE_DEST_STATUS
WHERE STATUS = 'VALID' AND TYPE = 'PHYSICAL';

ARCHIVED_SEQ# is the highest archived log sequence number shipped to this destination. APPLIED_SEQ# is the highest sequence applied on the standby. The delta tells you how many archive log sequences the standby is behind. This is a sequence-level measurement, not a time-based one: one sequence might represent 5 minutes or 50 minutes of redo depending on redo log size and generation rate.

This view is useful for a quick health check from the primary, but V$DATAGUARD_STATS on the standby gives the time-based lag values that map directly to RPO and RTO.

Checking MRP process status

Lag values assume the apply process is running. If MRP0 is not running, apply lag grows without bound and the standby is not a valid failover target. Check V$MANAGED_STANDBY:

-- Run on the standby database:
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#
FROM V$MANAGED_STANDBY
WHERE PROCESS LIKE 'MRP%' OR PROCESS = 'RFS';

If MRP0 does not appear in the results, media recovery is not running. The standby may be open READ ONLY without apply, or apply may have stopped due to an error. Status WAIT_FOR_LOG means MRP0 is waiting for the next log to arrive, which is normal between logs. Status APPLYING_LOG means it is actively recovering.

Gap detection: when redo sequences go missing

A redo gap occurs when the standby is missing one or more archive log sequences between the last applied sequence and the current sequence. Gaps block apply: MRP0 cannot apply sequence 1001 if it has not seen sequence 1000. Common causes include network outages that drop redo transport, primary archive log retention too short (logs deleted before the standby fetched them), or standby downtime longer than the primary’s archive retention window.

Check for gaps on the standby:

-- Run on the standby database:
SELECT * FROM V$ARCHIVE_GAP;

V$ARCHIVE_GAP returns rows only when there is a gap. No rows means no gap. If rows are present, the THREAD#, LOW_SEQUENCE#, and HIGH_SEQUENCE# columns identify the missing sequence range.

When a gap exists, it must be resolved before apply can proceed. With FAL (Fetch Archive Log) server and client configured, gaps often resolve automatically once connectivity is restored. If they do not, manually copy the missing archive logs from the primary to the standby and register them with ALTER DATABASE REGISTER LOGFILE.

From the primary side, the ARCHIVED_SEQ# minus APPLIED_SEQ# delta in V$ARCHIVE_DEST_STATUS also reveals a gap pattern: if the delta is growing and not shrinking, either standby apply is slow or there is a gap blocking progress.

SYNC transport and Maximum Protection: when standby health becomes primary health

In ASYNC transport mode, the primary ships redo to the standby without waiting for acknowledgment. Standby problems (network latency, slow I/O, MRP0 stopped) do not directly impact primary performance. The cost is that transport lag can grow without bound, increasing RPO exposure.

In SYNC transport mode (used in Maximum Availability and Maximum Protection), every primary commit waits for the standby to acknowledge receipt of the redo before the commit returns to the application. Standby and network health directly impact primary commit latency. A slow standby network path shows up on the primary as elevated log file sync wait times. The primary’s log file sync and the standby’s transport lag become correlated signals.

Maximum Protection goes further: if the primary loses contact with all SYNC standbys, it shuts itself down to prevent data loss. This is by design. Zero data loss (RPO of 0) is guaranteed even at the cost of primary availability. A standby going down in Maximum Protection mode causes a primary outage. This is the most aggressive Data Guard mode and must be operated with full awareness of this behavior.

In SYNC configurations, monitoring standby health is not just about failover readiness. It is about primary performance and availability right now. A transport lag spike in a SYNC configuration means primary commits are stalling.

Common misuses

Alerting on a single “lag” metric. Combining transport lag and apply lag into one alert loses the diagnostic information needed to respond correctly. Transport lag points to the network path. Apply lag points to the standby I/O and MRP. Split them.

Trusting zero lag without checking DATUM_TIME. A frozen DATUM_TIME with zero transport lag means the standby is disconnected, not healthy. Always check DATUM_TIME advancement alongside the lag value.

Querying V$DATAGUARD_STATS on the primary. The view returns no rows on the primary. Operators who do not know this assume the query failed or the standby is unreachable. Run it on the standby.

Assuming the Broker will alert when apply is stopped. If the Data Guard Broker intended state is APPLY-OFF, the Broker will not raise apply lag warnings even if the standby is 25 minutes behind. The database status shows SUCCESS because the intended state is being met. You must separately monitor the MRP0 process and the Broker intended state, not just rely on lag threshold alerts.

Ignoring standby redo log thread assignment. On 12c and later, standby redo logs created without specifying THREAD may be assigned to thread 0 and ignored by the apply process. This causes intermittent apply lag that cycles between seconds and minutes. The fix is to drop and recreate standby redo logs with explicit thread specification. This is a known, community-documented behavior change from 11g.

Signals to watch in production

How Netdata helps

Netdata’s Oracle Database monitoring collects per-second metrics that let you correlate Data Guard lag signals with primary and standby health in a single timeline.

• Transport lag and apply lag trends: per-second collection of V$DATAGUARD_STATS values lets you see lag growing before it breaches your RPO or RTO SLA.
• DATUM_TIME staleness detection: tracking DATUM_TIME alongside the lag values surfaces a frozen datum time even when the lag value itself reports zero.
• Primary-side correlation: redo generation rate, log file sync wait times, and archive destination status on the primary can be overlaid with standby lag to identify whether a transport lag spike correlates with a primary redo burst or a network event.
• MRP0 process monitoring: separate visibility into whether the apply process is running prevents the scenario where lag is growing but nobody noticed MRP0 stopped.
• Anomaly detection on lag patterns: flags unusual behavior like the intermittent cycling caused by standby redo log thread misassignment, even when the average lag looks acceptable.

For the full setup, see Oracle Database monitoring with Netdata.

Related guides

• How Oracle Database actually works in production: a mental model for operators
• Oracle archive log destination full: V$ARCHIVE_DEST_STATUS, the ERROR state, and space
• Oracle autoextend hit MAXSIZE: the space gotcha with a half-empty filesystem
• Oracle blocking sessions: finding the blocker at the head of the chain
• Oracle ‘buffer busy waits’: hot blocks, sequence headers, and index leaf splits
• Oracle buffer cache hit ratio: the most misused metric in Oracle monitoring
• Oracle ‘Thread N cannot allocate new log’: the archive hang that masquerades as up
• Oracle ‘Checkpoint not complete’: redo log sizing, DBWn, and log-switch stalls
• Oracle connection and session exhaustion: PROCESSES, SESSIONS, and pool sizing
• Oracle ‘cursor: pin S wait on X’: mutex contention on hot cursors
• Oracle ‘db file scattered read’: multiblock reads, full scans, and plan regressions
• Oracle ‘db file sequential read’: single-block index reads and buffer cache misses