SQL Server Always On Availability Groups (AG) mimarisinde karşımıza çıkan HADR_LOGCAPTURE_WAIT, veritabanı motorunun log kayıtlarını okuyup ikincil sunuculara (Secondary Replicas) göndermek üzere hazır hale getiremediği durumlarda oluşur.
Basitçe ifade etmek gerekirse: “Logları yakalayıp paketleyemiyorum, bu yüzden gönderemiyorum” durumudur.
Primary sunucuda bir “Log Scanner” (Log Tarayıcı) thread’i bulunur. Bu thread, Transaction Log dosyasını okur, paketler ve network üzerinden gönderilmesi için kuyruğa atar. Eğer bu okuma ve yakalama işlemi bir sebepten gecikirse, sistem HADR_LOGCAPTURE_WAIT uyarısı verir.
En Yaygın Nedenleri:
- Log Dosyası Okuma Hızı (I/O): Primary sunucuda Log dosyası (.ldf) üzerinde çok yoğun bir okuma/yazma baskısı olması.
- VLF (Virtual Log File) Parçalanması: Log dosyasının çok fazla (binlerce) küçük parçadan (VLF) oluşması, tarayıcının bu yapıyı okurken yavaşlamasına neden olur.
- İşlemci (CPU) Darboğazı: Log tarama işlemi CPU kullanan bir işlemdir. Eğer sunucu %100 CPU yükündeyse, logları paketleme hızı düşer.
- Yoğun Batch İşlemleri: Çok büyük verilerin tek bir işlemle eklenmesi veya silinmesi sırasında log üretim hızı, yakalama hızını aşabilir.
Bu bekleme tipi sisteminizde yüksekse, AG replikasyonunda gecikmelere (latency) neden olur. Çözüm için şu adımları izleyin:
A. VLF Sayısını Kontrol Edin
Log tarama performansını öldüren en büyük sinsi düşman fazla VLF sayısıdır. İlgili makale sayfadan bulunup okunabilir.
DBCC LOGINFO; -- Satır sayısı 1000'den fazlaysa sorun var demektir.- Çözüm: Log dosyasını küçültün (SHRINK) ve uygun “Growth” (Büyüme) ayarlarıyla (örneğin 1G) tekrar manuel olarak büyütün.
B. Disk Okuma Gecikmesini İzleyin
Log dosyasının bulunduğu diskin okuma hızını (Read Latency) test edilmesi gerekmektedir
SELECT io_stall_read_ms / num_of_reads AS [Avg Read Latency MS]
FROM sys.dm_io_virtual_file_stats(DB_ID('VeritabanıAdı'), 2);
- Eğer değer 10-20ms üzerindeyse, log diski yazma taleplerine yetişemiyor olabilir.
C. Log Dosyasını Ayrı Diske Alın
Data (.mdf) ve Log (.ldf) dosyaları aynı fiziksel disk setindeyse, veri okuma talepleri log yakalama işlemini yavaşlatabilir. Log dosyalarını her zaman en hızlı disk grubuna (NVMe/SSD) ve mümkünse data dosyalarından ayrı bir yere taşıyın. best practice olarak microsoft ayrı disk yollarında olmasını önermektedir.
D. Scan Parametrelerini Kontrol Edin
Çok nadir durumlarda, SQL Server’ın log yakalama hızını artırmak için gizli parametrelerle (Trace Flags) oynanabilir, ancak bu genellikle en son çaredir.
3. Özet Teşhis Tablosu
| Sorun | Belirti | Çözüm |
| Aşırı VLF | DBCC LOGINFO çok satır döndürüyor. | Log Shrink işlemi yapın. |
| Disk Darboğazı | Yüksek io_stall_read_ms değerleri. | Log dosyasını daha hızlı bir diske taşıyın. |
| Büyük İşlemler | Devasa INSERT/DELETE işlemleri. | İşlemleri küçük parçalara (Batching) bölün. |
| CPU Baskısı | Sistem genelinde yüksek CPU kullanımı. | Kaynakları optimize edin veya CPU artırın. |
Bu bekleme tipi genellikle Primary sunucu tarafındaki bir kaynak kısıtından kaynaklanır. Eğer sorun ağ hızı veya karşı sunucu hızı olsaydı, muhtemelen HADR_SYNC_COMMIT veya LOG_SEND_QUEUE gibi beklemeleri daha yoğun görürdünüz.
Başka makalede görüşmek dileğiyle..
“De ki: Ey Rabbim! İlmimi artır.” Taha-114
