Transaction Log Temizliği Nasıl Yönetilir?

Transaction Log'un Yapısı ve Önemi

Veritabanı yönetim sistemlerinde, transaction log (işlem günlüğü), sistemin dayanıklılığı ve tutarlılığının merkezinde yer alan kritik bir bileşendir. Bu yapı, veritabanında gerçekleştirilen tüm değişiklikleri kronolojik bir sırayla kaydeder, böylece her işlem için ayrıntılı bir kayıt tutar. Transaction log'un temel işlevi, olası bir sistem arızasından sonra veritabanını son tutarlı durumuna geri getirmeyi sağlamaktır.

Log dosyası, Write-Ahead Logging (WAL) prensibi ile çalışır; bu prensibe göre, herhangi bir veri sayfası diske yazılmadan önce, o veri sayfasında yapılacak değişikliğe ilişkin log kaydının diske kalıcı olarak yazılması gerekir. Bu mekanizma, ACID (Atomicity, Consistency, Isolation, Durability) ilkelerinden özellikle Dayanıklılık (Durability) ve Atomicity'nin garantisi için vazgeçilmezdir. Log yönetimi, veritabanı yöneticileri için performans ve kurtarma planlaması açısından en önemli sorumluluklardan biridir. Etkin bir şekilde yönetilmezse, log dosyası kontrolsüz bir şekilde büyüyerek disk alanını tüketebilir ve sistemin tamamen durmasına neden olabilir. Bu nedenle, log temizliği proaktif bir bakım faaliyeti olarak ele alınmalıdır.

Log Kaydı Türü	Açıklama	Temizleme Etkisi
BEGIN TRAN	İşlemin başlangıcını işaretler.	İşlem tamamlanana kadar temizlenemez.
INSERT, UPDATE, DELETE	Veri değişikliğinin fiziksel detaylarını içerir.	Checkpoint ve log kesme sonrası aktif olmayan kısımlar temizlenir.
COMMIT	İşlemin başarıyla tamamlandığını belirtir.	Bu kayıt, ilgili işlemin log kurtarma zincirini tamamlar.

Transaction log, veritabanının kalbidir ve asla göz ardı edilmemelidir.

Log Büyümesinin Nedenleri

Transaction log dosyasının beklenmedik veya aşırı büyümesi, veritabanı yöneticilerinin en sık karşılaştığı sorunlardan biridir. Bu durum, genellikle log dosyasının düzenli olarak kesilip yönetilmemesinden veya sistemdeki belirli işlem türlerinden kaynaklanır. Büyümenin arkasındaki temel sebep, aktif log kayıtlarının "etkin" (active) durumda kalması ve log kesme işleminin bu kayıtları serbest bırakamamasıdır. Bir log kaydı, ilgili olduğu işlem tamamlanmış olsa bile, henüz bir veritabanı yedeklemesi tarafından yakalanmadıysa aktif olarak kabul edilir.

Uzun süren ve henüz commit veya rollback edilmemiş büyük işlemler (transaction'lar), log dosyasının şişmesinin en belirgin nedenidir. Bu işlemler, tamamlanana kadar ilgili tüm log kayıtlarını aktif tutar. Benzer şekilde, toplu veri güncellemeleri, indeks yeniden oluşturma veya veri yükleme (ETL) işlemleri de çok fazla log alanı tüketebilir. Ancak, tek neden büyük işlemler değildir. Log yedekleme stratejisinin doğru yapılandırılmaması da aynı derecede önemli bir etkendir. Basit kurtarma modeline sahip bir veritabanında log otomatik olarak kesilebilirken, tam kurtarma modeli (FULL recovery model) güvenli kurtarma sağlamak için düzenli log yedeklemelerine ihtiyaç duyar. Bu yedeklemeler yapılmazsa, log dosyası sürekli büyümeye devam eder.

Veritabanı dosyalarının otomatik büyüme (autogrow) ayarları da log dosyasının fiziksel olarak şişmesine yol açabilir. Log dosyası parçalanmış ve büyüme artışı küçük ayarlanmışsa, sistem sürekli büyüme işlemi yaparak performansı düşürebilir ve dosya boyutunu kontrolsüz hale getirebilir. Ayrıca, log kayıtlarını tüketemeyen veya log alanını serbest bırakmayan replikasyon, CDC (Change Data Capture) veya uzun süre çalışan okuma işlemleri gibi sistem süreçleri de log büyümesine katkıda bulunur.

Log dosyasının beklenmedik büyümesinin en yaygın belirtisi "The transaction log for database 'X' is full" şeklindeki hata mesajıdır ve acil müdahale gerektirir.

Neden	Etki Mekanizması	Öncelik Seviyesi
Düzenli Log Yedeği Eksikliği	Aktif log zincirini kesemez, kayıtlar aktif kalır.	Yüksek
Uzun Süren Açık İşlemler	Log kesme noktasını ileri taşıyamaz.	Yüksek
Büyük Toplu İşlemler	Kısa sürede çok fazla log kaydı üretir.	Orta
Aktif Olmayan Dağıtıcılar (Replikasyon)	Okunmamış replikasyon komutları logu tutar.	Orta

Bu sorunları çözmek için, öncelikle log boyutunu ve kullanım yüzdesini izlemek esastır. Aşağıdaki basit sorgu, mevcut log dosyası kullanımını göstererek bir erken uyarı sistemi sağlar. Bu sorguyu düzenli olarak çalıştırmak, log dosyası dolmadan önce önlem almanıza olanak tanır.

DBCC SQLPERF(LOGSPACE);
-- Veya
SELECT DB_NAME(database_id) AS DatabaseName,
       name AS LogFileName,
       (size * 8 / 1024) AS LogSizeMB,
       (used * 8 / 1024) AS LogUsedMB,
       CAST(used AS float) / CAST(size AS float) * 100 AS LogUsedPercent
FROM sys.master_files
WHERE type_desc = 'LOG';

Temizleme ve Kesme Stratejileri

Transaction log temizliğini etkin bir şekilde yönetmek, doğru stratejilerin uygulanmasını gerektirir. Bu sürecin kalbinde "log kesme (log truncation)" işlemi yer alır. Kesme işlemi, artık sistem kurtarması için gerekli olmayan, yani bir veritabanı yedeğine dahil edilmiş olan aktif olmayan log kayıtlarını, log dosyasından fiziksel olarak silmez, yalnızca bu alanı yeniden kullanım için serbest bırakır. Bu kritik ayrımı anlamak, log alanı yönetimi için temeldir.

Hangi kayıtların kesilebileceği, büyük ölçüde veritabanının kurtarma modeline (recovery model) bağlıdır. Basit kurtarma modelinde, her bir checkpoint sonrasında sistem otomatik olarak kesilebilir log alanını serbest bırakır. Bu modelde log yedeklemesi mümkün olmadığından, noktasal kurtarma (point-in-time recovery) sağlanamaz. Tam kurtarma modeli ise, en eski aktif işleme kadar olan log kayıtlarının saklnmasını gerektirir. Bu nedenle, log alanını serbest bırakmanın tek yolu düzenli transaction log yedeklemeleri almaktır. Her log yedeği, o yedeğe kadar olan kayıtları artık "pasif" hale getirir ve bu alanın kesilmesine izin verir. Yedek alınmazsa, log dosyası sürekli büyür.

Log dosyasının kontrolsüz büyüdüğü acil durumlarda, genellikle log dosyasını hemen küçültmek için DBCC SHRINKFILE komutuna başvurulur. Ancak, bu yöntem geçici bir çözümdür ve kök nedeni ele almaz. Sık sık küçültme işlemi yapmak, log dosyasının parçalanmasına ve performans düşüşüne yol açabilir. Daha doğru yaklaşım, öncelikle log kesmenin önündeki engeli (genellikle eksik log yedeği veya uzun süren bir işlem) kaldırmak, ardından gerekirse kontrollü bir küçültme işlemi yapmaktır. Aşağıdaki kod, log kesme noktasını engelleyen en eski aktif işlemi bulmak ve log dosyasını küçültmek için kullanılabilir.

-- En eski aktif işlemi bulma (Tam Kurtarma Modelinde)
SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'VeritabaniAdiniz';

-- Log dosyasını belirli bir boyuta küçültme (Son Çare)
USE [VeritabaniAdiniz];
DBCC SHRINKFILE (N'LogDosyasiAdi', 1024); -- 1 GB'a küçült

Bulk-Logged kurtarma modeli, büyük toplu işlemler sırasında log büyümesini sınırlamak için tasarlanmıştır, ancak bu modelde de düzenli log yedeklemeleri gereklidir. Uygun stratejiyi seçmek, kurtarma gereksinimleri (RPO - Kurtarma Noktası Hedefi) ve performans arasında bir denge kurmak demektir. En iyi uygulama, tam kurtarma modeli ile düzenli log yedeklemelerini birleştirmek ve diski log dosyası için yeterli, sabit bir boyutta tutmaktır.

Log alanı sorunlarını gidermek için sistematik bir yaklaşım gereklidir. İlk adım, log kullanım durumunu ve bekleme nedenini kontrol etmektir. Ardından, aktif bir uzun işlem varsa sonlandırılmalı veya tamamlanması beklenmelidir. Eğer sorun eksik bir log yedeğiyse, derhal bir transaction log yedeği alınmalıdır. Ancak, log dosyası zaten tamamen dolmuşsa, yedek alınamayabilir; bu durumda kurtarma modeli geçici olarak SIMPLE'a alınıp bir checkpoint çalıştırmak gibi acil önlemler gerekebilir. Bu tür müdahalelerden sonra, mutlaka uygun kurtarma modeline ve düzenli yedekleme planına geri dönülmelidir.

Kurtarma Modeli	Log Kesme Prensibi	Kurtarma Yeteneği	Log Büyüme Riski
SIMPLE	Checkpoint sonrası otomatik.	En son tam/diferansiyel yedeğe kadar.	Düşük (ancak büyük işlemlerde yüksek).
FULL	Log yedeği (BACKUP LOG) sonrası.	Herhangi bir noktaya (point-in-time).	Yedekleme yoksa ÇOK YÜKSEK.
BULK_LOGGED	Log yedeği sonrası (toplu işlemler minimum loglanır).	Log yedeği içindeki toplu işlemler blok olarak kurtarılır.	Orta (toplu işlemlerde düşük).

En İyi Uygulamalar ve Otomasyon

Transaction log yönetimini reaktif bir sorun giderme faaliyeti olmaktan çıkarıp, proaktif ve sorunsuz bir sürece dönüştürmek için bir dizi en iyi uygulama (best practice) benimsenmelidir. Bu uygulamaların merkezinde, tutarlılık ve öngörülebilirlik vardır. İlk ve en kritik kural, log dosyasının boyutunu manuel olarak sık sık değiştirmekten kaçınmaktır. Bunun yerine, tipik iş yükünüz altında log dosyasının ulaştığı maksimum boyutu izleyin ve dosyayı, bu boyutu rahatça barındıracak, sabit bir boyuta ayarlayın. Bu, fiziksel büyüme operasyonlarının neden olduğu parçalanma ve performans cezasını ortadan kaldırır.

İkinci temel uygulama, iş gereksinimlerinize uygun bir kurtarma modeli seçmek ve bu modeli tutarlı bir şekilde uygulamaktır. Üretim sistemlerinde veri kaybına tolerans çok düşük olduğundan, tam kurtarma modeli genellikle tercih edilir. Ancak, bu modelin başarılı olması, otomatikleştirilmiş ve sık aralıklarla alınan transaction log yedeklerine sıkı sıkıya bağlıdır. Yedekleme sıklığı, kaybedebileceğiniz maksimum veri miktarını (RPO) belirler. Örneğin, 15 dakikada bir log yedeği almak, olası bir felakette en fazla 15 dakikalık veri kaybı riski taşıdığınız anlamına gelir.

Üçüncü önemli uygulama, kapsamlı bir izleme sistematiği kurmaktır. Log dosyası boyutu, kullanım yüzdesi ve log kesmeyi engelleyen durumlar (log_reuse_wait) düzenli olarak izlenmelidir. Bu izleme, basit bir T-SQL sorgusuyla yapılabileceği gibi, merkezi bir yönetim sunucsu veya üçüncü parti izleme araçları ile de gerçekleştirilebilir. Amaç, disk dolmadan veya kullanıcılar etkilenmeden önce uyarı almak ve harekete geçmektir. Ayrıca, uzun süren açık işlemler, killenmeyi gerektirebilecek terk edilmiş bağlantılar ve aşırı log üreten sorgular da düzenli denetim altında tutulmalıdır.

Tüm bu süreçlerin manuel yönetimi hataya açık ve zaman alıcıdır. Bu nedenle, otomasyon bir zorunluluktur. SQL Server Agent veya benzeri bir zamanlayıcı kullanılarak, transaction log yedeklemesi, boş alan kontrolleri ve temizlik işlemleri zamanlanabilir. Aşağıdaki örnek, yedekleme ve izleme süreçlerini birleştiren basit bir otomasyon çerçevesi sunar. Bu script, log kullanımı belirli bir eşiği aştığında otomatik olarak bir log yedeği alır ve ardından bir uyarı e-postası gönderir.

-- Basit bir Otomatik Log Yönetimi Kontrolü (Konsept)
DECLARE @DBName NVARCHAR(128) = N'VeritabaniAdiniz';
DECLARE @LogUsedPercent FLOAT;
DECLARE @Threshold FLOAT = 70.0; -- Eşik yüzdesi
DECLARE @BackupPath NVARCHAR(500) = N'F:\LogBackups\';

-- Log kullanımını kontrol et
SELECT @LogUsedPercent = CAST(used AS float) / CAST(size AS float) * 100
FROM sys.master_files
WHERE type_desc = 'LOG' AND DB_NAME(database_id) = @DBName;

-- Eşik aşıldıysa, log yedeği al ve uyar
IF @LogUsedPercent > @Threshold
BEGIN
    DECLARE @FileName NVARCHAR(500);
    SET @FileName = @BackupPath + @DBName + '_Log_' + REPLACE(REPLACE(REPLACE(CONVERT(NVARCHAR, GETDATE(), 120), '-', ''), ':', ''), ' ', '_') + '.trn';
    
    BACKUP LOG @DBName TO DISK = @FileName WITH INIT, COMPRESSION;
    
    -- Burada bir e-posta uyarısı tetiklenebilir (sp_send_dbmail vb.)
    PRINT 'Log yedeği alındı: ' + @FileName + ' (Kullanım: %' + CAST(@LogUsedPercent AS NVARCHAR(10)) + ')';
END

Otomasyonun bir diğer boyutu, ldf dosyasının fiziksel büyümesini yönetmektir. Otomatik büyüme (autogrow) bir güvenlik ağı olarak açık bırakılmalı, ancak boyut artışı (growth increment) yüzde (%) yerine sabit bir megabayt (MB) değerine (örneğin 512 MB veya 1024 MB) ayarlanmalıdır. Bu, büyüme olaylarının öngörülebilir olmasını ve dosya parçalanmasının azalmasını sağlar. Ayrıca, log dosyasını veri dosyalarından farklı, yüksek hızlı bir depolama birimine (SSD gibi) yerleştirmek, log yazma performansını önemli ölçüde artıracaktır.

Son olarak, olağanüstü durum kurtarma (DR) planlarınızın transaction log yedeklerini de içerdiğinden emin olun. Log yedeklerinin nasıl ve nereye alındığı, ne kadar süre saklandığı ve kurtarma senaryolarında nasıl uygulanacağı açıkça belgelenmelidir. Log yönetimi, düzenli bakım, izleme ve otomasyonla sorunsuz hale getirilebilir. Bu disiplinli yaklaşım, hem veri güvenliğini garanti altına alır hem de üretim ortamlarında karşılaşılabilecek en yaygın ve kritik kesintilerden birini önler.

Herhangi bir değişiklik yapmadan önce, özellikle üretim ortamlarında, yedeklemelerin düzgün çalıştığından ve kurtarma prosedürlerinin test edildiğinden emin olun. Transaction log yönetimi, veritabanının sağlığı ve kullanılabilirliği için kritik bir sorumluluktur ve her zaman veri koruma ilkeleri çerçevesinde ele alınmalıdır.