SQL Server’da bir işlem (Transaction) yapıldığında, bu işlemin detayları önce log kayıtlarına yazılır. Daha sonra bu log kayıtlarını okuyup başka bir yere aktarması gereken mekanizmalar devreye girer.
LOG_CONSUMERSET, log kayıtlarını okuyan bir iş parçacığının (thread), bu kayıtları tüketecek olan diğer iş parçacıklarıyla koordinasyon sağlamaya çalışırken beklediği süredir.
- Always On (AG): Primary node üzerindeki log kayıtlarının Secondary node’lara gönderilmek üzere paketlenmesi aşamasında.
- Transactional Replication: Log Reader Agent’ın logları okuyup dağıtıcıya (distributor) iletmesi sırasında.
- Change Data Capture (CDC): Değişen verilerin logdan okunup yakalanması sürecinde.
Kısacası:
Sql serverda yapılan işlemler log dosyasına yazıldığı anda aynı işlemler sql server always on yapısı sayesinde log flush işlemi ile secondary sunucusuna gönderilmek isteniyor. Bu işlemlerde aşırı yükten dolayı sql server çalışamaz hale gelmektedir.
Eğer bu bekleme tipi sisteminizde en üst sıralardaysa, bu bir “tıkanıklık” (bottleneck) olduğuna işaret eder. Şu adımları izleyerek sorunu daraltabilirsiniz:
A. Always On (AG) Sağlığını Kontrol Edin
Eğer AG kullanıyorsanız, ikincil sunucuların (Secondary Replicas) geride kalıp kalmadığını kontrol edin.
- Log Send Queue: Eğer gönderim kuyruğu şişmişse, ağ hızı (Network Latency) veya ikincil sunucunun disk yazma hızı bu beklemeye neden oluyor olabilir.
B. Transactional Replication / CDC İncelemesi
- Log Reader Agent: Eğer bir replikasyon varsa, Log Reader’ın taradığı işlem sayısı çok fazlaysa bu beklemeyi tetikler. Çok büyük “Batch” işlemlerinden (tek seferde milyonlarca satır silme/güncelleme) kaçının.
- CDC Tarama Hızı: CDC aktifse, tarama (scan) işinin parametrelerini (maxtrans, maxscans) optimize ederek log tüketimini hızlandırın.
C. VLF (Virtual Log File) Sayısını Kontrol Edin
Transaction Log dosyanızda çok fazla VLF (sanal log dosyası) varsa (örneğin 10.000+), log okuyucu mekanizmalar bu logları tararken zorlanır.
- Çözüm: Log dosyasını küçültüp (Shrink) uygun büyüklükteki parçalarla tekrar büyütmek VLF sayısını düşürür ve tüketim hızını artırır.
D. Disk ve Ağ Performansı
Log tüketimi doğrudan I/O ve Network hızıyla ilgilidir. Log dosyasının bulunduğu disklerin gecikme (Latency) sürelerini kontrol edin (ideali 5ms altıdır).
Özet
| Olası Neden | Gösterge | Çözüm |
| Ağ Gecikmesi | AG Log Send Queue artışı. | Bant genişliğini artırın veya sıkıştırma (compression) kullanın. |
| Yüksek VLF Sayısı | DBCC LOGINFO çıktısında binlerce satır. | Log dosyasını shrink edin ve manuel büyütün. |
| Büyük İşlemler | Tek bir DELETE veya UPDATE ile milyonlarca satır. | İşlemleri küçük parçalara (batches) bölün. |
| Yavaş Secondary Disk | Secondary sunucuda HADR_SYNC_COMMIT beklemeleri. | İkincil sunucunun disk performansını iyileştirin. |
Başka makalede görüşmek dileğiyle..
“De ki: ‘Sizinle benim aramda şahit olarak Allah yeter. Çünkü O, kullarından hakkıyla haberdardır, onları hakkıyla görendir.’ “İsra Suresi; 96. Ayet
