SQL Server VLF Sayısı: Çok Fazla VLF Neden Sorun Olur ve Nasıl Düzeltilir?

SQL Server’da bazı performans sorunları hiçbir sorgu planında, hiçbir bekleme istatistiğinde açıkça görünmez. Bir veritabanının açılması dakikalar sürer, bir restore beklenenden çok daha uzun tamamlanır, Always On secondary’si sürekli geride kalır ama nedenini bulmak zordur. Bu sorunların arkasında çoğu zaman transaction log’un içindeki görünmez bir yapı vardır: VLF (virtual log file) sayısı.

Bu yazıda VLF’nin ne olduğunu, nasıl oluştuğunu, çok fazla VLF’nin hangi sorunlara yol açtığını, VLF sayısının nasıl ölçüleceğini ve log dosyasının doğru VLF dağılımıyla nasıl yeniden yapılandırılacağını adım adım anlatıyoruz.

VLF (Virtual Log File) Nedir?

SQL Server, her transaction log dosyasını (.ldf) içeride virtual log file adı verilen parçalara böler. Log, bu parçalar üzerinde döngüsel olarak çalışır: yeni kayıtlar log’un sonuna yazılır, artık ihtiyaç duyulmayan VLF’ler temizlenip (truncation) yeniden kullanılır. Log temizlemesi ve log küçültme işlemleri VLF sınırlarında gerçekleşir.

VLF’lerin sayısı ve boyutu yönetici tarafından doğrudan ayarlanamaz. SQL Server bunları log dosyası oluşturulurken veya her büyüdüğünde, büyüme miktarına göre kendisi belirler. Yani VLF sayısı, log dosyasının nasıl büyüdüğünün doğrudan bir sonucudur.

VLF’ler Nasıl Oluşur?

Microsoft’un belgelediği kurala göre, log dosyası her büyüdüğünde oluşturulan VLF sayısı büyüme miktarına bağlıdır:

Sorun buradan doğar: eski varsayılan değerlerle (log için %10 veya 1 MB autogrowth) yıllardır çalışan bir veritabanında log, binlerce küçük adımla büyümüş olabilir. Her küçük büyüme birkaç küçük VLF ekler ve sonunda log dosyası on binlerce, hatta yüz binlerce VLF’ten oluşur. SQL Server 2016’dan itibaren yeni veritabanlarında log autogrowth varsayılanı 64 MB’tır, ancak eski sürümlerden yükseltilen veya taşınan veritabanları eski ayarlarını korur.

Tersi de sorun olabilir: log dosyasını tek seferde çok büyük bir adımla büyütmek, az sayıda ama çok büyük VLF oluşturur. Bu durumda log temizlemesi büyük parçalar halinde gerçekleşir ve log alanı verimli kullanılamaz. Hedef, ne çok fazla küçük ne de birkaç dev VLF’tir.

Çok Fazla VLF Hangi Sorunlara Yol Açar?

SQL Server, veritabanı recovery’sinin ilk aşamasında log dosyasındaki tüm VLF’leri tarayıp bir liste oluşturur. VLF sayısı arttıkça bu tarama uzar. Microsoft’a göre çok sayıda VLF şu sorunlara yol açabilir:

• Uzun veritabanı açılışı: SQL Server yeniden başlatıldığında veya bir failover sonrasında veritabanının recovery’yi tamamlaması çok uzun sürer.
• Yavaş restore ve attach: veritabanını geri yüklemek veya attach etmek beklenenden çok daha uzun sürer. Bu, felaket anında RTO’nuzu doğrudan uzatır.
• Yavaş log backup’lar.
• Replication, CDC ve Always On gecikmesi: Log Reader Agent, transactional replication için her VLF’yi taramak zorundadır. Always On secondary’lerinde redo gecikmesi artar.
• Mirroring kurulumunda zaman aşımları (1413, 1443, 1479 hataları) ve restore sırasında 701 gibi bellek hataları.

Bu etkiler özellikle VLF sayısı on binler ve yüz binler mertebesine ulaştığında belirginleşir. Microsoft, toplam VLF sayısını en fazla birkaç bin ile sınırlı tutmayı önerir.

Error log’daki işaretler

SQL Server 2012 ve sonrasında, bir veritabanı açılırken, restore edilirken veya attach edilirken VLF sayısı 10.000’i aşıyorsa error log’a 9017 numaralı bir bilgi mesajı yazılır: “Database … has more than … virtual log files which is excessive.” Ayrıca error log’da bir veritabanının “Starting up database” mesajı ile recovery’nin “Analysis … Phase 1 of 3” mesajı arasında dakikalar geçiyorsa, bu da yüksek VLF sayısının tipik bir belirtisidir. Error log’u nasıl okuyacağınızı SQL Server Error Log rehberimizde anlattık.

VLF Sayısı Nasıl Ölçülür?

SQL Server 2016 SP2 ve sonrasında VLF bilgisi iki dinamik yönetim fonksiyonuyla alınır. sys.dm_db_log_info, eski DBCC LOGINFO komutunun yerini alır; sys.dm_db_log_stats ise özet bilgileri verir. Sunucudaki tüm veritabanları için:

SELECT d.name,
       d.recovery_model_desc,
       ls.total_vlf_count,
       ls.active_vlf_count,
       CAST(ls.total_log_size_mb AS decimal(18, 2)) AS total_log_size_mb,
       CAST(ls.total_log_size_mb / NULLIF(ls.total_vlf_count, 0) AS decimal(18, 2)) AS avg_vlf_size_mb,
       ls.log_truncation_holdup_reason
FROM sys.databases AS d
CROSS APPLY sys.dm_db_log_stats(d.database_id) AS ls
WHERE d.state_desc = N'ONLINE'
ORDER BY ls.total_vlf_count DESC;

Sonucu yorumlarken yalnızca VLF sayısına değil, ortalama VLF boyutuna da bakın. 50 GB’lık bir log’da 20.000 VLF (ortalama 2,5 MB) açık bir sorundur. 50 GB’lık bir log’da 200 VLF (ortalama 250 MB) ise makul bir dağılımdır. log_truncation_holdup_reason sütunu da log’un neden temizlenemediğini gösterir; düzeltme öncesinde bunun NOTHING veya geçici bir değer olması gerekir.

Yüksek VLF Sayısı Nasıl Düzeltilir?

Düzeltmenin mantığı basittir: log dosyasını olabildiğince küçültmek, ardından ihtiyaç duyulan boyuta az sayıda, kontrollü adımla yeniden büyütmek ve autogrowth değerini düzeltmek. Başlamadan önce geri yüklenebilir bir backup’ınız olduğundan emin olun.

1. Log’un temizlendiğinden emin olun

Log yalnızca sonundaki VLF’ler kullanılmıyorsa küçülebilir. Full recovery model’de önce bir log backup alın; log_truncation_holdup_reason değeri LOG_BACKUP veya ACTIVE_TRANSACTION ise önce bu nedeni çözün. Ayrıntılar için SQL Server Transaction Log Çok mu Büyük? yazımıza bakabilirsiniz.

USE [SalesDB];

BACKUP LOG [SalesDB]
TO DISK = N'E:\Backup\SalesDB_LOG_before_vlf_fix.trn'
WITH COMPRESSION, CHECKSUM;

-- Aktif VLF'ler log'un neresinde? Sondaki VLF'ler aktifse shrink hedefe inmez.
SELECT TOP (5) vlf_sequence_number, vlf_begin_offset, vlf_size_mb, vlf_active
FROM sys.dm_db_log_info(DB_ID())
ORDER BY vlf_begin_offset DESC;

2. Log’u küçültün

-- Log dosyasının logical adı
SELECT name, size / 128 AS size_mb FROM sys.database_files WHERE type = 1;

-- Olabildiğince küçült (hedef MB)
DBCC SHRINKFILE (N'SalesDB_log', 0);

-- Sonuç: kaç VLF kaldı?
SELECT COUNT(*) AS vlf_count FROM sys.dm_db_log_info(DB_ID());

Aktif log, dosyanın sonundaki VLF’lerde bulunuyorsa ilk denemede yeterince küçülmeyebilir. Bu durumda bir log backup daha alıp (full modda) shrink’i tekrarlamak genellikle yeterlidir. Shrink işleminin ayrıntıları için SQL Server Shrink İçin Best Practices yazımıza bakabilirsiniz.

3. Log’u hedef boyuta kontrollü adımlarla büyütün

Log’u gerçek ihtiyacına (en yoğun dönemindeki kullanımına) göre boyutlandırın. Büyük bir hedef boyuta tek adımda çıkmak çok büyük VLF’ler, çok küçük adımlarla çıkmak çok fazla VLF oluşturur. Pratik bir yaklaşım, hedefe 8 GB’lık adımlarla ilerlemektir; 1 GB’tan büyük her büyüme 16 VLF oluşturduğu için her adım yaklaşık 512 MB’lık VLF’ler ekler:

-- Hedef: 32 GB log, yaklaşık 512 MB'lık VLF'lerle
ALTER DATABASE [SalesDB] MODIFY FILE (NAME = N'SalesDB_log', SIZE = 8192MB);
ALTER DATABASE [SalesDB] MODIFY FILE (NAME = N'SalesDB_log', SIZE = 16384MB);
ALTER DATABASE [SalesDB] MODIFY FILE (NAME = N'SalesDB_log', SIZE = 24576MB);
ALTER DATABASE [SalesDB] MODIFY FILE (NAME = N'SalesDB_log', SIZE = 32768MB);

-- Sonraki büyümeler için sabit autogrowth
ALTER DATABASE [SalesDB] MODIFY FILE (NAME = N'SalesDB_log', FILEGROWTH = 512MB);

Daha küçük log’lar için adım boyutunu orantılı olarak küçültün; örneğin 4 GB’lık bir log için 1 GB’lık adımlar yeterlidir. Microsoft, mevcut log boyutuna göre en uygun VLF dağılımını ve büyüme adımlarını hesaplayan bir scripti de GitHub’daki Tiger Toolbox deposunda yayımlar.

4. Autogrowth ayarını kalıcı olarak düzeltin

SELECT DB_NAME(database_id) AS database_name,
       name AS logical_name,
       CAST(size AS bigint) * 8 / 1024 AS size_mb,
       CASE WHEN is_percent_growth = 1
            THEN CAST(growth AS varchar(10)) + ' %'
            ELSE CAST(CAST(growth AS bigint) * 8 / 1024 AS varchar(10)) + ' MB'
       END AS autogrowth
FROM sys.master_files
WHERE type = 1
ORDER BY is_percent_growth DESC, growth;

Yüzde ile büyüyen veya 1–10 MB gibi çok küçük adımlarla büyüyen her log dosyası, gelecekte yüksek VLF sayısının adayıdır. Yukarıdaki örnekte ise 32 GB’lık log’a eklenen 512 MB’lık bir büyüme, mevcut boyutun 1/8’inden küçük olduğu için tek bir 512 MB’lık VLF oluşturur; böylece log büyüse bile VLF dağılımı düzgün kalır.

Always On ve Log Shipping Ortamlarında Dikkat

Sık Sorulan Sorular