Standby'da transport/apply lag, apply hızı ve Data Guard süreçlerini ölç

Komut

-- Standby'da calistir:
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 hizi (KB/sn):
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 ve apply surecleri (12.2+; v$managed_standby'in yerini alir):
SELECT name, role, action, thread#, sequence#, block#, delay_mins
FROM   v$dataguard_process
ORDER  BY role;

Ne yapar?

Standby'ın primary'den ne kadar geride olduğunu (transport lag = alınmamış redo, apply lag = uygulanmamış redo), birikmiş redo'nun ne zaman biteceğini, apply hızını ve hangi sürecin hangi sequence'ı işlediğini gösterir.

Ne zaman kullanılır?

RPO/RTO izlemede, lag alarmında sorunun ağda (transport) mı yoksa standby I/O/CPU'sunda (apply) mı olduğunu ayırt etmek için.

Dikkat

Salt okunurdur. datum_time eskiyse (time_computed'dan çok gerideyse) standby primary'den veri almıyordur ve lag değeri güvenilmezdir. Apply lag ile birlikte DelayMins tanımlı olup olmadığını kontrol et; bilinçli gecikme lag gibi görünür.