Oracle Database / Data Guard & High Availability
Separate Data Guard apply lag from redo transport delay
A standby can receive redo promptly while recovery applies it slowly. Compare apply and transport metrics rather than treating all lag as network latency.
Environment and inputs: Oracle Database 19c baseline · SQL*Plus-compatible SQL unless RMAN, DGMGRL, ADRCI or a host shell is specified. Check release, patch level, edition and container first.
Start with this diagnostic
Use the stated SQL, RMAN, DGMGRL or host shell and replace sample names with approved targets. DBA and V$ views need authorized catalog access in the correct container. Do not grant broad privileges for an example.
SELECT name, value, unit, datum_time FROM v$dataguard_stats WHERE name IN ('transport lag','apply lag');
Read the result
On the standby, the pair helps distinguish delayed delivery from delayed application when the metric data is fresh.
Resolve and verify
Correlate lag with recovery process state, storage latency and primary workload. Address the demonstrated apply constraint and monitor catch-up under normal redo volume.
Operational precautions
Do not stop apply to clear an error message or assume adding CPU alone removes an I/O-bound backlog.