log_reuse_wait_desc Nedir ve Ne Anlatır?

Direnc Onen

sys.databases sistem tablosundaki log_reuse_wait_desc sütunu, bir veritabanının transaction log dosyasındaki boş alanın neden yeniden kullanılamadığını gösterir.

Eğer transaction log dosyanız sürekli büyüyorsa veya temizlenmiyorsa, bu sütun nedenini anlamak için en önemli kaynaktır.

Değer	log_reuse_wait_desc	Açıklama
0	NOTHING	Şu anda yeniden kullanılabilir sanal log dosyaları (VLF) bulunmaktadır.
1	CHECKPOINT	Son log küçültme işleminden bu yana bir checkpoint gerçekleşmedi.
2	LOG_BACKUP	Transaction log'un küçültülmesi için bir log yedeği alınması gerekmektedir.
3	ACTIVE_BACKUP_OR_RESTORE	Bir veri yedekleme veya geri yükleme işlemi devam ediyor.
4	ACTIVE_TRANSACTION	Devam eden bir işlem var ve log küçültme engelleniyor.
5	DATABASE_MIRRORING	Veritabanı mirroring işlemi duraklatıldı veya geride kaldı.
6	REPLICATION	Transaction replication nedeniyle log küçültülemiyor.
7	DATABASE_SNAPSHOT_CREATION	Bir veritabanı anlık görüntüsü (snapshot) oluşturuluyor.
8	LOG_SCAN	Log tarama işlemi devam ediyor.
9	AVAILABILITY_REPLICA	Always On Availability Group replikası log kayıtlarını uyguluyor.
10-12	(Kullanımda değil)	İç kullanım için ayrılmıştır.
13	OLDEST_PAGE	Dolaylı checkpoint nedeniyle en eski sayfa log küçültmeyi geciktiriyor.
14	OTHER_TRANSIENT	Bu değer şu an kullanılmamaktadır.
16	XTP_CHECKPOINT	Memory-Optimized Tables için bir checkpoint işlemi gereklidir.

log_reuse_wait_desc Değerini Nasıl Görebilirim?

Aşağıdaki sorgu ile log_reuse_wait_desc değerini kontrol edebilirsin:

SELECT name, recovery_model_desc, log_reuse_wait_desc 
FROM sys.databases 
WHERE name = 'VeritabaniAdi';

log_reuse_wait_desc Sorununu Çözmek İçin Ne Yapılmalı?

LOG_BACKUP → Log yedeği al (FULL Recovery kullanıyorsan)

BACKUP LOG [VeritabaniAdi] TO DISK = 'C:\Backup\VeritabaniAdi.trn'

ACTIVE_TRANSACTION → Uzun süren işlemi bul ve gerekirse sonlandır

DBCC OPENTRAN('VeritabaniAdi'); -- Açık transaction'ları gör
KILL <SPID>; -- Uzun süren işlemi sonlandır (dikkatli ol!)

CHECKPOINT → Manuel Checkpoint çalıştır

CHECKPOINT;

LOG Dosyasını Temizle (Shrink)

DBCC SHRINKFILE (VeritabaniAdi_Log, 100); -- 100MB'e küçült

AlwaysOn ve Mirroring Durumunda, Senkronizasyonu Kontrol Et

SELECT * FROM sys.dm_hadr_database_replica_states WHERE database_id = DB_ID('VeritabaniAdi');

log_reuse_wait_desc: OLDEST_PAGE Ne Anlama Geliyor?

Eğer log_reuse_wait_desc değeri OLDEST_PAGE ise, bu şu anlama gelir:

Lazy Writer işlemi, en eski dirty page'leri diske yazmadığı için transaction log temizlenemiyor.

Kirli Sayfa (Dirty Page) Nedir? SQL Server'da, veri sayfaları bellekte değiştirildiğinde ancak henüz diske yazılmadığında "kirli sayfa" olarak adlandırılır.

Bu durum TEMPDB hariç tüm veritabanlarında görülebilir ve genellikle disk I/O darboğazları veya bellek yetersizliği nedeniyle oluşur.

OLDEST_PAGE Sebepleri

Disk I/O Yavaşlığı:

• SQL Server, değişen verileri diske yazarken gecikme yaşıyor olabilir.

• Disk darboğazlarını ve I/O gecikmelerini kontrol etmelisin.

Bellek Yetersizliği:

• Bellek (RAM) yeterli değilse, SQL Server değişiklikleri diske yazmada gecikme yaşayabilir.

• Sorgu belleği tüketimini ve Page Life Expectancy (PLE) değerini kontrol etmelisin.

Checkpoint Çalıştırılmıyor:

• Checkpoint işlemi gecikmiş olabilir, bu yüzden log dosyası eski dirty page’leri temizleyemiyor.

• Checkpoint manuel olarak tetiklenebilir.

Lazy Writer Gecikmesi:

• Lazy Writer işlemi normalden daha yavaş çalışıyor olabilir.

• Lazy Writer çalışma hızını kontrol etmek gerekebilir.

Çözüm Önerileri

Aşağıdaki adımlarla OLDEST_PAGE sorununu çözebilirsin:

Checkpoint Çalıştır

İlk olarak, manuel CHECKPOINT işlemi yaparak değişiklikleri diske yazmayı zorla:

CHECKPOINT;

Birkaç saniye bekledikten sonra tekrar log_reuse_wait_desc değerini kontrol et:

SELECT name, log_reuse_wait_desc 
FROM sys.databases 
WHERE name = 'VeritabaniAdi';

Eğer OLDEST_PAGE hala devam ediyorsa, bir sonraki adımlara geçelim.

Disk I/O Performansını Kontrol Et

SQL Server’ın disk işlemlerinde bir darboğaz olup olmadığını görmek için şu sorguyu çalıştır:

SELECT * FROM sys.dm_io_virtual_file_stats(DB_ID('VeritabaniAdi'), NULL);

Eğer io_stall_ms değerleri çok yüksekse, disk I/O gecikmesi yaşıyorsun demektir. Çözüm için:

• Disk performansını kontrol et.

• NVMe SSD gibi daha hızlı diskler kullanabilirsin.

• RAID veya SAN gibi disk yapısını gözden geçir.

io_stall_ms Nedir?

sys.dm_io_virtual_file_stats DMV’sinde bulunan io_stall_ms, SQL Server'ın bir veri veya log dosyasına erişirken ne kadar süre beklediğini (I/O gecikmesi) milisaniye (ms) cinsinden gösterir.

• Yüksek io_stall_ms değerleri, SQL Server’ın diskten veri okurken veya yazarken gecikme yaşadığını gösterir.

• Düşük değerler ise I/O işlemlerinin hızlı çalıştığını ifade eder.

Bu değer diskin türüne ve altyapıya bağlı olarak değişir. Ancak genel referans değerleri aşağıdaki gibidir:

Disk Türü	Okuma (read_io_stall_ms)	Yazma (write_io_stall_ms)	Toplam (io_stall_ms)
NVMe SSD	0.1 - 2 ms	0.1 - 2 ms	0.1 - 5 ms
PCIe SSD	1 - 5 ms	1 - 5 ms	1 - 10 ms
SATA SSD	2 - 8 ms	2 - 10 ms	5 - 15 ms
SAN Storage (Hızlı)	5 - 15 ms	5 - 20 ms	10 - 30 ms
SAN Storage (Orta Seviye)	10 - 20 ms	15 - 30 ms	20 - 50 ms
RAID HDD (SAS 15K RPM)	15 - 30 ms	20 - 40 ms	30 - 60 ms
RAID HDD (SATA 7200 RPM)	20 - 50 ms	30 - 70 ms	50 - 100 ms
Tek Disk HDD (Mekanik)	50 - 150 ms	70 - 200 ms	100 - 300 ms

Page Life Expectancy (PLE) Değerini Kontrol Et

Bellek yetersizliği olup olmadığını anlamak için PLE değerini kontrol edebilirsin:

SELECT object_name, counter_name, cntr_value 
FROM sys.dm_os_performance_counters 
WHERE counter_name = 'Page Life Expectancy';

Page Life Expectancy (PLE) değeri 300 saniyenin (5 dakika) altında ise, belleğin yetersiz olabilir.

Çözüm:

• Daha fazla RAM ekle veya

• Bellek tüketen sorguları optimize et.

Lazy Writer Durumunu Kontrol Et

Lazy Writer işlemi, kirli sayfaları (dirty pages) bellekte gereğinden uzun tutuyor olabilir. Bunu kontrol etmek için:

SELECT * FROM sys.dm_os_process_memory;

Eğer lazy_writer_sleep süresi çok uzunsa, bellekte gereksiz yük olabilir.

Çözüm:

• Bellek tüketen sorguları belirleyip iyileştir.

• sp_whoisactive veya sys.dm_exec_requests kullanarak en çok kaynak tüketen işlemleri bul.

Alternatif Olarak Transaction Log'u Küçültme

Eğer CHECKPOINT çalıştırdıktan sonra bile log dosyan temizlenmiyorsa, transaction log dosyanı (LDF) manuel olarak küçültmek yardımcı olabilir:

DBCC SHRINKFILE (VeritabaniAdi_Log, 100); --100 değeri MB cinsinden değerdir. 

Dikkat! Eğer transaction log’un hala doluysa ve aktif transaction’lar devam ediyorsa, küçültme işlemi bir işe yaramaz.

Özet

• log_reuse_wait_desc, transaction log’un neden temizlenemediğini gösterir.

• Değerler, CHECKPOINT, LOG_BACKUP, ACTIVE_TRANSACTION gibi farklı nedenleri açıklıyor.

• Çözüm, soruna göre BACKUP LOG, DBCC OPENTRAN, CHECKPOINT, DBCC SHRINKFILE gibi işlemlerle sağlanabilir.