MSSQL Server Transaction Log Dosyası Nedir

Bu makalede sql server transaction log dosyasını ele almış olacağız. Veritabanı altında yapılan tüm işlemler transaction log dosyasına kaydedilir. Kaydedilen bu işlemler aşağıda belirtilmiştir.

• INSERT, UPDATE, DELETE işlemleri
• Başlatılan ve tamamlanan transactions (işlemler)
• ROLLBACK ve COMMIT noktaları
• Index oluşturma
• Sayfa taşımaları
• Checkpoint bilgileri

Transaction log dosyası her veritabanı altında bir tane bulunmaktadır. Gerçek veri tutmasa dahi sql için hayati bir öneme sahiptir. Transaction log dosyalarındaki her kayıt unique bir değere sahiptir. Bu değer ismi LSN(log sequence number) değerine sahiptir. LSN transaction dosyalarımızın tekil eşsiz olmasını sağlayan bir yapı olarak karşımıza çıkmaktadır. Adeta bir zincir halkalarının birbirine bağlanmış şekli olarak düşünebiliriz. Bu LSN değerlerinin birinin olmaması transaction yapısının bozulmasına sebep olur.

Kısacası LSN:

LSN (Log Sequence Number) bir veri değil, bir işaretleyici / konum belirtecidir.
LSN’nin içinde veri bulunmaz.
LSN sadece bir log kaydının nerede olduğunu tanımlar.

Transaction log dosyaları sistemin istenilen veya istenmeyen bir durumda kapanması sonucunda veritabanının tutarlılığını transaction log dosyasıyla sağlamaktadır. Transaction log dosyasında tamamlanan veriler mdf veya ndf dosyasına yazılmaktadır. Veritabanı tutarlı yapıya geçerken bu ifadeye roll forward denilir. Tamamlanmayan ifadeler ise roll back yapar. Bu yapı sql server ACID kurallarından biri olan Consistency olarak karşımıza çıkmaktadır. Yani veritabanı tutarlığını sql server garanti altına alır.

Veritabanı altında sadece bir transaction log dosyası olduğunu söylemiştim. Birden fazla log dosyasının olmasının veritabanının performansı açısından bir değer ifade etmeyecektir. Çünkü veritabanı sadece bir log dosyasına yazma işlemini gerçekleştirir. Herhangi bir sorun anından ikinci log dosyası oluşturulup veritabanının bu log dosyası üzerinde büyümesi istenebilir.

SQL Server’ın .ldf (log dosyası) formatı binary (ikili) formatta saklanır.

Aşağıdaki komut, transaction log içerisindeki ham işlemleri listeler.

SELECT
    [Current LSN], 
    [Operation], 
    [Transaction Name], 
    [Transaction ID], 
    [Begin Time], 
    [End Time], 
    [Page ID], 
    [Slot ID], 
    [RowLog Contents 0]
FROM fn_dblog(NULL, NULL);

Aktif olan lsn değerlerini görmek için aşağıdaki komut kullanılır:

SELECT
--  db_name(database_id),
	database_id,
    last_sent_lsn,
    last_received_lsn,
    last_redone_lsn
FROM sys.dm_hadr_database_replica_states;

Secondary sunucu, kendi LSN değeriyle eşleşen log içeriğini doğrudan kendi başına oluşturamaz. İçeriği Primary sunucudan almak zorundadır.

Always On yapılarındaki Synchronous Mode da olan sunucular arasında veri transferi nasıl olmaktadır.

Primary Sunucusu Nereden Alır?

• Primary veritabanının LDF dosyasındaki LSN kayıtları, log blocks halinde log capture mekanizması tarafından alınır.
• Bu log verisi, SQL Server’ın Log Transport Layer bileşeni tarafından secondary sunucuya gönderilir.

Secondary Sunucusu Nasıl Alır?

• SQL Server, log bloklarını sıralı LSN’ler ile gönderir.
• Secondary sunucuda, redo thread bu logları işler.
• Bu işlem, sıfır veri kaybı garantisi (sync mode) için LSN onaylanana kadar primary’de commit yapmaz.

Secondary Sunucusu Nereye Yazar?

• Secondary sunucu, gelen log kayıtlarını kendi .ldf dosyasına yazar.
• Yani her secondary sunucuda da kendi LDF dosyası vardır ve log verisi primary ile aynı LSN sırasına göre işlenir.
• Ardından, redo thread gelen logları veri dosyasına (MDF) uygular.

Örnek Senaryo:

Primary Sunucu:

• INSERT gibi bir işlem yapar
• Bu işlem LDF dosyasına yazılır (örneğin LSN: 00000023:000000fa:0001)
• Log Capture Thread, bu log’u yakalar
• Log Send Thread, bunu ağ üzerinden Secondary’ye gönderir

Secondary Sunucu:

• LSN değerini alır (ama veri henüz yok!)
• Log Receive Thread, log içeriğini LSN ile eşleşen şekilde alır
• Redo Thread, bu log kayıtlarını işler ve veri dosyasına (.mdf) yazar

Önceki makalelerimde yapmış olduğum AlwaysOn, Log Shipping, Database Mirroring yapımızın transaction log dosyasını referans aldığını görmüştük.

Hangi log dosyasının ne kadar dolu olduğunu görmek için kullanılır.

DBCC SQLPERF(LOGSPACE);

Transaction log dosyaları içerisinde gerçek veriler tutulmaz sadece insert update delete işlemleriyle ilgili bilgi tutar biz log backup alarak truncate olmasını sağlarız ve full backup restore ettikten sonra log backup’ı üzerine eklersek veriler gelmektedir. Hangi log dosyasında gerçek veriler yoktu bu veriler nerden geldi diyebiliriz. Şimdi bu yapıyı açıklayalım. Transaction Log (LDF) dosyasında gerçek veri tutulur mu?

Doğrudan gerçek veriler (SELECT ile gördüğün tablo satırları gibi) değil, yapılan işlemlerin (INSERT, UPDATE, DELETE) log kayıtları tutulur. Bu kayıtlar:
• Hangi tabloda,
• Hangi satıra,
• Ne tür işlem yapıldı,
• Önceki ve sonraki değer neydi (değişiklik varsa),
• Transaction kim tarafından ne zaman başlatıldı vs. gibi bilgiler içerir. Ama bu, veri dosyasındaki (MDF) satır-satır veri yapısından farklıdır.

Peki restore sırasında veriler nasıl geri geliyor?

Senaryo:
1. Full Backup aldın → MDF’deki veriler yedeklenir.
2. Log Backup aldın → Aradaki işlemler (transaksyonlar) yedeklenir.
3. Restore yaptın:
• Önce full backup restore edilir → tablonun son full backup’taki hali yüklenir.
• Sonra log backup’lar uygulanır → aradaki INSERT, UPDATE, DELETE işlemleri tekrar işlenerek veriler en güncel haline gelir.

Veriler nereden geldi?

Veriler doğrudan LDF’den gelmiyor, log backup uygulanınca SQL Server, bu loglar içindeki işlemleri sırayla tekrar çalıştırıyor (replay). Böylece veri dosyası (MDF) içeriği güncellenmiş hale geliyor.

Yani:
• Gerçek veriler: MDF (veri dosyasında)
• İşlem geçmişi: LDF (log dosyasında)
• Restore sonrası verinin oluşumu: Full backup + işlem loglarının tekrar oynatılmasıyla

Hangi log dosyasında gerçek veri yoktu? LDF (Transaction Log) dosyasında tam veri tablosu hali yoktur.
Sadece işlemler vardır. Bu nedenle: Log backup’ı restore ettiğimizde, veriler LDF’den alınmaz, loglardaki işlemlerle MDF dosyası güncellenir.

Özetle:
• Gerçek veriler MDF dosyasındadır.
• LDF işlemlerin geçmişini tutar.
• Log backup’lar uygulandığında veri, loglardan değil, o loglarla yapılan işlemler sonucu oluşur.

Başka makalede görüşmek dileğiyle.

Göklerin ve yerin hükümranlığı Allah’ındır. Dönüş de ancak Allah’adır. Nûr -42