OracleData Guard
Transport and apply lag
How far behind the standby is in receiving and applying redo. A growing apply lag with no transport lag points at the apply process, not the network.
Not yet verified. How scripts are tested
1CLEAR COLUMNS2SET LINESIZE 120 PAGESIZE 100 TRIMOUT ON TAB OFF3COLUMN name FORMAT A204COLUMN value FORMAT A185COLUMN time_computed HEADING "COMPUTED" FORMAT A206COLUMN datum_time HEADING "DATUM" FORMAT A207 8SELECT name, value, time_computed, datum_time9FROM v$dataguard_stats10WHERE name IN ('transport lag', 'apply lag', 'apply finish time');Save it as ora-dg-lag.sql and run it with SQL> @ora-dg-lag.
Part of these runbooks
More Oracle scripts: Data Guard
- Redo apply and transport processesWhich Data Guard processes are running and what they're doing. No MRP0 row means redo is arriving but not being applied. Before 12.2, query…
- Redo destinations and transport errorsEvery active archive destination with its status, gap state and last error. Any text in the ERROR column means redo isn't reaching that standby.
- Archive gaps and last applied sequenceMissing log sequences the standby is waiting for, then the last applied sequence per thread. Compare with the current sequence on the primary.
- Data Guard errors and warnings, last 24 hoursMessages Data Guard wrote to V$DATAGUARD_STATUS, filtered to warnings and errors. Run on both sides.
- Standby redo log configurationStandby redo logs by thread. You want one more group per thread than you have online log groups, all the same size as the online logs.
- Broker health checks (DGMGRL)The broker's own view of the configuration. VALIDATE DATABASE is the best single readiness check before a switchover.