SQL Server Transaction Log Architecture – Part I

Yeni bir veri tabanı oluşturduğumuzda varsayılan olarak iki file oluşur. Bunlardan biri data file olan mdf, diğeri ise transaction logları saklayan ldf’tir. Bu makale serisine konu olan transaction log file ve mekanizmasını inceliyor olacağız. Başlamadan önce SQL Server Transaction Log mimarisini anlayabilmek için, basit terimlerin ne anlama geldiğini açıklayalım.

Bu terimler şunlar:

  • Transaction: Veri tabanında meydana gelen değişiklikler kümesidir.
  • Commit: Transaction’ın başarılı bir şekilde tamamlanmasıdır.
  • Roll back: Transaction’ın iptal edilmesi ve geri alınma işlemidir.
  • Logging: Veri tabanı tutarlılığını sağlamak amacıyla yapılan loglama işlemidir.
  • Transaction log: Log kayıtlarının saklandığı log file’a verilen isimdir.
  • Crash: SQL Server’ın beklenmedik bir şekilde kapanmasıdır.
  • Recovery: Crash meydana geldiğinde veri tabanının tutarlılığını korumak ve kurtarmak amacıyla gerçekleştirilen işlemdir.
  • Checkpoint: Buffer poolda yer alan dirty pagelerin diske flush edilme işlemidir. Detaylı olarak açıklanacak.
  • HADR: High Availability / Disaster Recovery
  • ACID: (A)tomicity, (C)onsistency, (I)ndependent, (D)urability.

Peki log ve logging neden önemlidir ve gereklidir?

  • Logging, gerçekleşen transactionların kalıcı bir şekilde saklanabilmesi ve olası felaket durumlarında kurtarma ve geri dönüş işleminin gerçekleşebilmesi
  • Değişikliklerin eksiksiz olarak tutulması ve saklanması
  • Gerçekleşen tüm değişikliklerin, veri tabanında yansıması sonrası, ACID prensiplerinden Durability prensibini sağlaması için
  • Logging, HADR çözümlerinde büyük önem taşımaktadır. Çünkü tüm yapı neredeyse bu alt yapı üzerinde kurgulanmıştır desek yanlış olmaz. Örnek vermek gerekirse Mirroring çözümünde, principal db’den mirror db’e transfer edilen tüm veri, log mekanizması üzerinden gerçekleşmektedir. SQL Server 2012 ile birlikte sunulan Availability Groups çözümü de Mirroring çözümünde yer alan benzer yapı ile çalışmaktadır. Diğer çözümler ise transactional replication ve database snapshotdır. Database snapshot, snapshot ı alınan db üzerinde, snapshot alındıktan sonra gerçekleşen değişiklikleri (değişen pageleri) snapshot db de tutabilmek amacıyla log mekanizmasını kullanmaktadır. Ayrıca change data capture (cdc)ı da sayabiliriz.

Veri tabanında gerçekleşen basit bir update transaction ın log tarafına nasıl yansıdığına bakalım:

  1. Eğer query de transaction açıkça belirtilmemişse (explicit) SQL Server bizim için implicit bir transaction oluşturur
  2. Değişikliğin uygulanacağı page, buffer pool da değilse, diskten okuma yapılır, daha sonra memory e çekilir (latch, physical read)
  3. Tutarlılığı sağlamak amacıyla sırasıyla table, page ve row a lock konulur
  4. Buffer pool da yer alan page(ler)de değişiklik uygulanır
  5. Buffer pool da transaction ın roll back ve commit operasyonuna tabii olabilmesi için log kaydı oluşturulur
  6. Değişiklik uygulandıktan sonra buffer pool da yer alan log kaydı, transaction log’a gönderilir (log file)
  7. Eğer mirroring ya da availability group çözümleri varsa ve sync replica mevcutsa, log kaydının diğer node(lar)a da ulaştırılması ve uygulandığına dair mesaj alınması beklenir. Bu nedenle bu tür HADR çözümlerinde, log üretmenin önemi büyüktür.
  8. Tüm locklar kaldırılır ve kaynaklar (row>page>table) serbest bırakılır
  9. Transaction commit edilir ve query i gönderen kaynağa mesaj ve/veya result döndürülür. ‘206 rows affected.’ gibi.
  10. Buffer pool’da değişikliğe uğrayan pagelere dirty page işareti konulur. Bunun sebebi değişikliğin henüz diske kalıcı olarak yansımamasıdır. SQL Server tarafından yönetilen ve belirli aralıklar ile çalışan checkpoint işlemi sırasında bu dirty pagelerin diske flush edilmesidir.

Bu süreçler yerine gerçekleşen değişiklikleri doğrudan diske yazsaydık, daha kolay olmaz mıydı?

Bu sorunun cevabı, hem performans, hem güvenilirlik, hem de tutarlılık açısında hayırdır. Nedeni ise, diske direkt yazılsaydı, memoryden (30GB/sn-550MB/sn) neredeyse 10 kat daha yavaş olan disklerle anlık çalışmak, performansı olumsuz etkileyecek, ek olarak diske yazılma esnasında karşılaşılan beklenmedik sistem kesintileri ya da erişim sorunları sonucu veri kaybı ya da tutarsızlığı meydana gelecekti. Yukarıdaki adımlarda, güvenilirlik, tutarlılık, dayanıklılık ve performans amacıyla, kaynaklar izole ediliyor, I/O işlemleri gerçekleşiyor, log kaydı yazılıyor ve en son memory den diske flush ediliyor.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir