dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #41
oracle
ReplicationSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minsSYSDBA / DBA / SELECT_CATALOG_ROLE

Oracle Data Guard Apply/Transport Gecikmesi: Güvenli Teşhis

Transport ve apply lag'i ayırır, archive gap, ağ veya standby I/O sorununu bulur; broker yönetimini bozmadan toparlanmayı doğrular.

İlişkili Metrik:M42
İlişkili Script:S71
#data-guard#apply-lag#transport-lag#broker#rpo

Operasyonel Güvenlik ve Risk Uyarısı

Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- Standby M42 apply lag yükseliyor, broker `WARNING`/`ERROR` bildirebilir; felaket kurtarma RPO'su riske girer.

- Transport lag ve apply lag birbirinden farklı davranabilir; sıfır olmayan her değer hata değildir.

2. Etki / Impact

Standby verisi geride kalır; failover'da veri kaybı veya RTO uzaması mümkündür. Okuma standby'larında veri eskir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. Fiziksel standby'da S71 ve güncellik bilgisine bakın:
sql
SELECT name, value, unit, time_computed, datum_time
FROM v$dataguard_stats
WHERE name IN ('transport lag','apply lag','apply finish time');

SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;
SELECT dest_id, status, error FROM v$archive_dest
WHERE status <> 'INACTIVE';

`datum_time` eskiyse “lag=0” bile veri akışının durduğunu gizleyebilir.

🟢 Salt Okunur2. Broker etkinse DGMGRL ile durumları kontrol edin:
text
dgmgrl /
DGMGRL> SHOW CONFIGURATION;
DGMGRL> SHOW DATABASE VERBOSE 'standby_db_unique_name';
🟢 Salt Okunur3. **Transport lag** varsa primary archive destination, ağ/DNS ve listener'ı; **transport normal, apply lag** varsa standby CPU/I/O, redo apply ve archive gap'i inceleyin. Primary/standby redo boyutu/üretim hızı ve FRA doluluğu karşılaştırın.
🟢 Salt Okunur4. 12c'deki `v$managed_standby` görünümü 12.2'den itibaren deprecated'dir; 19c'de mümkünse `v$dataguard_process`, broker ve `v$dataguard_stats` kullanın. RAC'te thread ve instance farklarını ayırın.

4. Müdahale / Response

🟡 Geri Alınabilir1. Ağ veya disk kapasitesi sorununu giderin; eksik archive log'un mevcut yedekte bulunup bulunmadığını doğrulayın. Standby'a ulaştırılmamış archive log'ları **silmeden önce** `oracle-fra-full` içindeki koruma koşullarını uygulayın.
🟡 Geri Alınabilir2. Broker yönetiyorsa apply'ı broker üzerinden kontrol edin; durdurup başlatmak toparlanma yaratabilir fakat neden çözülmediyse sorun tekrarlanır:
text
DGMGRL> EDIT DATABASE 'standby_db_unique_name' SET STATE='APPLY-OFF';
DGMGRL> EDIT DATABASE 'standby_db_unique_name' SET STATE='APPLY-ON';

**Yalnızca apply gerçekten durmuşsa ve planlı müdahale onaylandıysa** yapın; çalışan apply'ı sırf lag var diye kesmeyin.

🔴 YÜKSEK RİSK / GERİ ALINAMAZ3. Gap logları artık yoksa `RESETLOGS`, `ACTIVATE STANDBY DATABASE` veya uydurma log kaydıyla ilerlemeyin; yedeklerden eksik archive log'ları restore edin veya standby'ı desteklenen yöntemle yeniden oluşturun.

4. 12c/19c Real-Time Apply, broker ve lisans/opsiyon koşulları ortamdan ortama farklıdır; konfigürasyonu doğrulamadan `USING CURRENT LOGFILE` gibi sürüme özel sözdizimine güvenmeyin.

5. Doğrulama / Verification

- `datum_time` güncel; transport ve apply lag azalıp RPO sınırına döndü; `v$archive_gap` boş ve broker sağlıklı.

- Aynı primary transaction'ının standby'da uygulandığını kontrollü uygulama testiyle doğrulayın.

6. Geri Alma / Rollback

- Broker ile apply kapatıldıysa `APPLY-ON` ile açın; kapalı kaldığı sürede biriken gecikmeyi izleyin.

- Yeniden oluşturulan standby'ın geri alınması basit değildir; başlamadan önce yedek ve failover planını doğrulayın.

Diğer ORACLE Runbook'ları