Medir o lag de transporte/aplicação, a taxa de aplicação e os processos do Data Guard no standby

Comando

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

O que faz

Mostra quanto o standby está atrás do primário (transport lag = redo ainda não recebido, apply lag = redo ainda não aplicado), quando o acúmulo será aplicado, a taxa de aplicação e qual processo trabalha em qual sequence.

Quando usar

Para monitoramento de RPO/RTO e, em um alerta de lag, para saber se o problema está na rede (transporte) ou em I/O/CPU do standby (aplicação).

Atenção

Somente leitura. Se datum_time estiver antigo (muito atrás de time_computed), o standby não está recebendo dados do primário e o valor do lag não é confiável. Verifique se DelayMins está definido; um atraso intencional parece apply lag.