standby에서 transport/apply lag, apply 속도, Data Guard 프로세스 측정

명령어

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

하는 일

standby가 primary보다 얼마나 뒤처졌는지(transport lag = 아직 수신하지 못한 redo, apply lag = 아직 적용하지 못한 redo), 밀린 redo가 언제 적용될지, apply 속도, 어떤 프로세스가 어느 sequence를 처리 중인지 보여 준다.

사용 시점

RPO/RTO 모니터링, lag 알림 시 문제가 네트워크(transport)인지 standby I/O/CPU(apply)인지 판별하기 위해.

주의

읽기 전용. datum_time이 오래되었으면(time_computed보다 크게 뒤처짐) standby가 primary로부터 데이터를 받지 못하는 것이며 lag 값은 신뢰할 수 없다. DelayMins가 설정되어 있는지 확인한다. 의도적인 지연은 apply lag처럼 보인다.