SQL Server veritabanlarımızın Transaction Loglarını nasıl tutacağımızı belirlediğimiz üç farklı Recovery Model seçeneğimiz vardır.
- Full
- Simple
- Bulk-Logged
Fakat, bu modeli anlatmadan önce kısaca Commit ve Checkpoint kavramlarına değinmek istiyorum.
Bir Log File içerisini görebilseydik en basit haliyle karşımıza böyle bir görsel çıkıyor olacaktı.
Resim – 1
SQL Server üzerinde gerçekleşen Transactionlar, Log File içerisindeki Virtual Log File’ları üzerinde tutulur. Resimde göreceğiniz gibi T1 adlı Transaction’ın başladığı, yürütülen işlemi ve sonlandığı yani Commit edildiğine dair bilgiler yazılır. Tüm bu işlemler gerçekleşirken SQL Server periyodik olarak Checkpoint noktaları oluşturur. Bu noktalar sayesinde ise verilerin artık fiziksel olarak data dosyasına yazıldığı anlamını çıkartabiliriz. Kullanılmayan ve Aktif olarak belirttiğim kısımlara ise Simple modelinde değineceğim.
Bu kısa ön bilgilendirmeden sonra artık Recovery Modellerin nasıl çalıştığı konusuna geçebiliriz.
Full
Veritabanı üzerindeki yapılan bütün işlemler Transaction Log dosyasına yazılır. Bu model özellikle Disaster Recovery çözümlerinin uygulanabilmesi için kullanacağınız modeldir. Point in Time Restore sayesinde istediğiniz zaman dilimine geri dönmenizi sağlayabilir. Bu açıdan da en güvenli Recovery Modeldir.
Fakat, gün içerisinde yapılacak yoğun (Insert, Update, Delete) DML operasyonları Log dosyamızı büyüteceği için müdahale ederek bunu olması gereken boyutlara çekebiliriz. Bunun için ilk yöntem Differential Transaction Log Backup almaktır. Böylece Backup alınmış bölüm Loglardan çıkartılmış olur. İkici yöntem ise tercih etmenizi çok tavsiye etmiyeceğim Recovery Modeli Simple’a çevirerek Commit olmuş kısımını Shrink ederek temizleme yöntemidir.
Simple
Transaction Log yapısını anlatmaya çalıştığım görsel üzerinde Kullanılmayan ve Aktif olmak üzere iki bölüm olduğunu görebilirsiniz. İşte simple recovery modelin temel çalışma prensibi burada devreye giriyor.
Eski ve Commit olmuş işlemler ilk Checkpoint noktasından sonra artık ihtiyaç duyulmaz ve silinirler.
Özellikle SQL dilini yeni öğrenen biriyseniz yazacağınız hatalı sorgular ve büyük veri içeren tabloları manipüle ederken Log dosyasını çok fazla büyümesine yol açarak Log ve Disk limitlerine ulaşabilirsiniz. İşte Simple Model ile bu gibi durumlarda hızlıca Loglarımızı silmek bizlere ciddi kolaylık sağlayabiliyor.
Fakat, Transaction Loglar silindiği için Full Recovery Modeldeki gibi Loglardan Restore almak mümkün değil. Bu yüzden geriye dönük çeşitli veri kayıpları yaşayabilirsiniz.
Bulk-Logged
Özel bir kullanımı olan bu model, yüksek ölçekli verilerin Bulk işlemler sayesinde en az seviyede Log tutmasını daha hızlı aktarılmasını sağlar. Bulk işlemler haricinde Full model gibi tüm transaction logları tutmaktadır. Bu yüzden Bulk-Logged modelde Full Recovery Model gibi bir felaket anında loglardan geriye dönüş yapmanız mümkün değildir.
Bu yüzden günlük kullanım için uygun bir model değildir.
Bu Recovery Modelleri veritabanlarınızın arayüzü seçeneklerinden değiştirebilirsiniz. Benim tercihim bunun yerine kodlarla değiştirmenizden yana olacak.
–Bulk-Logged Recovery Model
ALTER DATABASE [DatabaseName] SET RECOVERY BULK_LOGGED
–Full Recovery Model
ALTER DATABASE [DatabaseName] SET RECOVERY FULL
–Simple Recovery Model
ALTER DATABASE [DatabaseName] SET RECOVERY SIMPLE
Tabi bu komutları çalıştırabilmeniz için belirli bir yetki düzeyine ve çalıştırdığınızda veritabanı üzerinde kimsenin işlem yapmıyor olduğundan emin olmanız gerekir.
Eğer isterseniz komutların sonuna WITH NO_WAIT hint’i ekleyerek önlem alabilirsiniz. Bu sayede herhangi bir işlem yapılıyorsa bir çeşit hata ekranıyla karşılaşacaksınız.
Transaction Log yapıları ve Recovery Modeller bizlerin daha optimize işlemler yapabilmesi için bilinmesi gereken en temel konulardan biridir. Önümüzdeki yazılar içerisinde buradan yola çıkarak işlemlerinizin üzerindeki etkileri anlatmaya çalışacağım.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
TAGs: SQL Server, Database, Recovery Model, Commit, Checkpoint, Log File, Virtual Log File,SQL Server Recovery Model
