Medir el lag de transporte/aplicación, la velocidad de aplicación y los procesos de Data Guard en el 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;

Qué hace

Muestra cuánto va retrasado el standby respecto al primario (transport lag = redo aún no recibido, apply lag = redo aún no aplicado), cuándo se aplicará el atraso, la velocidad de aplicación y qué proceso trabaja en qué secuencia.

Cuándo usarlo

Para el monitoreo de RPO/RTO y, ante una alerta de lag, para saber si el problema está en la red (transporte) o en la I/O/CPU del standby (aplicación).

Precaución

Solo lectura. Si datum_time es antiguo (muy por detrás de time_computed), el standby no está recibiendo datos del primario y el valor de lag no es fiable. Compruebe si DelayMins está definido; un retraso intencionado parece apply lag.