Transport-/Apply-Lag, Apply-Rate und Data-Guard-Prozesse auf dem Standby messen

Befehl

-- Run on the standby:
SELECT name, value, unit, time_computed, datum_time
FROM   v$dataguard_stats
WHERE  name IN ('transport lag','apply lag','apply finish time','estimated startup time');

-- Redo apply rate (KB/s):
SELECT item, units, sofar, total, TO_CHAR(timestamp,'YYYY-MM-DD HH24:MI:SS') AS ts
FROM   v$recovery_progress
WHERE  item IN ('Active Apply Rate','Average Apply Rate','Maximum Apply Rate','Last Applied Redo')
ORDER  BY start_time DESC, item;

-- Transport and apply processes (12.2+; replaces v$managed_standby):
SELECT name, role, action, thread#, sequence#, block#, delay_mins
FROM   v$dataguard_process
ORDER  BY role;

Was es tut

Zeigt, wie weit der Standby hinter der Primary liegt (Transport-Lag = noch nicht empfangenes Redo, Apply-Lag = noch nicht angewendetes Redo), wann der Rückstand angewendet sein wird, die Apply-Rate und welcher Prozess an welcher Sequence arbeitet.

Wann einsetzen

Für RPO-/RTO-Monitoring und bei einem Lag-Alarm, um zu erkennen, ob das Problem im Netzwerk (Transport) oder bei I/O/CPU des Standby (Apply) liegt.

Vorsicht

Nur lesend. Ist datum_time alt (weit hinter time_computed), empfängt der Standby keine Daten von der Primary und der Lag-Wert ist unzuverlässig. Prüfe, ob DelayMins gesetzt ist; eine absichtliche Verzögerung sieht wie Apply-Lag aus.