OracleData Guard

Redo apply and transport processes

Which 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 V$MANAGED_STANDBY instead.

Not yet verified. How scripts are tested

1CLEAR COLUMNS2SET LINESIZE 140 PAGESIZE 100 TRIMOUT ON TAB OFF3COLUMN name        FORMAT A64COLUMN role        FORMAT A245COLUMN action      FORMAT A146COLUMN client_role HEADING "CLIENT ROLE" FORMAT A187COLUMN thread#     HEADING "THREAD"      FORMAT 9998COLUMN sequence#   HEADING "SEQUENCE"    FORMAT 999999999COLUMN block#      HEADING "BLOCK"       FORMAT 999999999910 11SELECT name, role, action, client_role, thread#, sequence#, block#12FROM v$dataguard_process13ORDER BY name;

Save it as ora-dg-process.sql and run it with SQL> @ora-dg-process.

Open in denrepo

Part of these runbooks

• Data Guard check

More Oracle scripts: Data Guard

• Transport and apply lagHow 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.
• 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.