SQL Server’da LOGBUFFER, bir işlemin (transaction) gerçekleşmesi sırasında oluşturulan log kayıtlarının, diskteki log dosyasına yazılmadan önce bellekte tutulduğu Log Buffer (Log Tamponu) alanında yer kalmamasını ifade eder.
Basit bir tabirle: “Log yazma sırası bekleyen veriler için bellekteki küçük geçici depo doldu, yeni gelen veriler kapıda bekliyor.”
Bu bekleme tipi genellikle saniyenin çok altında (milisaniyeler seviyesinde) gerçekleşir. Ancak sisteminizde bir darboğaz haline gelmişse sebepleri şunlardır:
- Yavaş Disk Alt Yapısı: Log Buffer’daki veriler diske (.ldf dosyasına) yeterince hızlı boşaltılamıyordur. Diskin yazma hızı (Write Throughput), log üretim hızının altındadır.
- Aşırı Yoğun Küçük İşlemler: Saniyede binlerce küçük INSERT veya UPDATE işlemi yapılıyorsa, Log Buffer sürekli dolar ve boşalır.
- Transaction Log Dosyası Darboğazı: Log dosyasının bulunduğu diskin doluluk oranı veya I/O kapasitesinin (IOPS) zirveye ulaşması.
- Hatalı Log Dosyası Yapılandırması: Log dosyasının çok küçük artışlarla (Autogrow) büyümesi veya çok fazla VLF (Sanal Log Dosyası) içermesi.
WRITELOG ile Farkı:
Bu iki bekleme tipi birbirine çok yakındır ancak odak noktaları farklıdır:
- WRITELOG: “Logu diske yazma emrini verdim, diskin ‘yazdım’ demesini bekliyorum.” (Odak: Disk hızı).
- LOGBUFFER: “Logu diske göndermek için bellekteki tampon bölgeye koymak istiyorum ama tampon bölge dolu, yer açılmasını bekliyorum.” (Odak: Veri üretim hızı ve tampon yönetimi).
Eğer LOGBUFFER beklemesi sisteminizde en üst sıralardaysa şu adımları izlemelisiniz:
A. Disk Yazma Gecikmesini (Latency) Kontrol Edin
Log dosyasının bulunduğu diskteki yazma gecikmesini şu sorguyla analiz edin:
SELECT io_stall_write_ms / num_of_writes AS [Avg Write Latency MS]
FROM sys.dm_io_virtual_file_stats(DB_ID('VeritabanıAdı'), 2); -- 2 = Log dosyası
- 1ms – 5ms: İdeal.
- 10ms – 20ms+: Disk yavaştır, LOGBUFFER beklemelerinin ana sebebi budur.
B. İşlemleri Toplu Yapın (Batching)
Her bir satırı ayrı ayrı COMMIT etmek yerine, işlemleri büyük bloklar halinde yapın.
- Kötü: 10.000 kez INSERT + COMMIT.
- İyi: BEGIN TRAN + 10.000 INSERT + COMMIT.
C. Log Dosyasını Optimize Edin
- VLF Kontrolü: DBCC LOGINFO ile VLF sayısına bakın. Çok fazlaysa log dosyasını küçültüp (Shrink) büyük parçalarla tekrar büyütün.
- Ayrı Disk: Log dosyasını mutlaka veri (.mdf) dosyalarından farklı, yüksek hızlı (SSD/NVMe) bir diske taşıyın.
D. Delayed Durability (Gecikmeli Dayanıklılık)
Eğer sisteminizde milisaniyelik veri kaybı kabul edilebilir bir riskse:
- ALTER DATABASE [DB_NAME] SET DELAYED_DURABILITY = FORCED; komutu, Log Buffer’ın diske yazılma zorunluluğunu esneterek bu beklemeyi neredeyse tamamen ortadan kaldırır.
Özetle
| Durum | Olası Neden | Aksiyon |
| Sürekli yüksek değerler | Disk I/O sınırı | Log dosyasını daha hızlı bir diske taşıyın. |
| Anlık zirveler | Büyük veri yükleme (Bulk Load) | Veri yükleme sırasında TABLOCK kullanın veya Recovery Model’i Simple / Bulk-Logged yapın. |
| Çok sayıda ufak işlem | Sık COMMIT kullanımı | Kodunuzda Transaction yönetimini optimize edin (Batching). |
Başka makalede görüşmek dileğiyle..
Anne babaya kaba davranmayın İsra-23
