# log\_reuse\_wait\_desc Nedir ve Ne Anlatır? **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ğerlog_reuse_wait_descAçıklama
0NOTHINGŞu anda yeniden kullanılabilir sanal log dosyaları (VLF) bulunmaktadır.
1CHECKPOINTSon log küçültme işleminden bu yana bir checkpoint gerçekleşmedi.
2LOG_BACKUPTransaction log'un küçültülmesi için bir log yedeği alınması gerekmektedir.
3ACTIVE_BACKUP_OR_RESTOREBir veri yedekleme veya geri yükleme işlemi devam ediyor.
4ACTIVE_TRANSACTIONDevam eden bir işlem var ve log küçültme engelleniyor.
5DATABASE_MIRRORINGVeritabanı mirroring işlemi duraklatıldı veya geride kaldı.
6REPLICATIONTransaction replication nedeniyle log küçültülemiyor.
7DATABASE_SNAPSHOT_CREATIONBir veritabanı anlık görüntüsü (snapshot) oluşturuluyor.
8LOG_SCANLog tarama işlemi devam ediyor.
9AVAILABILITY_REPLICAAlways On Availability Group replikası log kayıtlarını uyguluyor.
10-12(Kullanımda değil)İç kullanım için ayrılmıştır.
13OLDEST_PAGEDolaylı checkpoint nedeniyle en eski sayfa log küçültmeyi geciktiriyor.
14OTHER_TRANSIENTBu değer şu an kullanılmamaktadır.
16XTP_CHECKPOINTMemory-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: ```sql 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)** ```sql BACKUP LOG [VeritabaniAdi] TO DISK = 'C:\Backup\VeritabaniAdi.trn' ``` **ACTIVE\_TRANSACTION → Uzun süren işlemi bul ve gerekirse sonlandır** ```sql DBCC OPENTRAN('VeritabaniAdi'); -- Açık transaction'ları gör KILL ; -- Uzun süren işlemi sonlandır (dikkatli ol!) ``` **CHECKPOINT → Manuel Checkpoint çalıştır** ```sql CHECKPOINT; ``` **LOG Dosyasını Temizle (Shrink)** ```sql DBCC SHRINKFILE (VeritabaniAdi_Log, 100); -- 100MB'e küçült ``` **AlwaysOn ve Mirroring Durumunda, Senkronizasyonu Kontrol Et** ```sql 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.** {% hint style="info" %} **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. {% endhint %} 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: ```sql CHECKPOINT; ``` Birkaç saniye bekledikten sonra tekrar `log_reuse_wait_desc` değerini kontrol et: ```sql 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: ```sql 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. {% hint style="success" %} #### **`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. {% endhint %} 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: ```sql 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: ```sql 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: ```sql 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.