Mesurer le transport/apply lag, le débit d'apply et les processus Data Guard sur la standby

Commande

-- 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;

Ce que fait la commande

Indique le retard de la standby sur la primaire (transport lag = redo pas encore reçu, apply lag = redo pas encore appliqué), quand l'arriéré sera appliqué, le débit d'apply et quel processus travaille sur quelle séquence.

Quand l'utiliser

Pour la surveillance RPO/RTO et, sur une alerte de lag, pour déterminer si le problème est dans le réseau (transport) ou dans les E/S/CPU de la standby (apply).

Attention

Lecture seule. Si datum_time est ancien (très en retard sur time_computed), la standby ne reçoit pas de données de la primaire et la valeur de lag n'est pas fiable. Vérifiez si DelayMins est défini ; un délai intentionnel ressemble à un apply lag.