Transaction Logs ve Recovery Models
0

Bu kavramlar SQL Server‘da kurtarma senaryolarında birbiriyle ilişkili bir şekilde çalışır. Transaction Logların nasıl tutulması gerektiğini veri tabanının Recovery Model özelliği belirler.

Recovery Model Transaction Log bakımını denetlemek üzere tasarlanmıştır.

Transactionların nasıl loglara kaydedildiğini,

Transaction Logların yedeklenip yedeklenmeme durumlarını,

Ne tür bir restore işleminin kullanılabilir olduğunu belirleyen bir veritabanı özelliğidir.

3 tip Recovery Model bulunmaktadır:

  • Full Recovery Model
  • Bulk-Logged Recovery Model
  • Simple Recovery Model

Bu modellere değinmeden önce değinmemiz gereken konu ise;

‘Transaction Log dediğimiz kavram nedir?’

SQL Server veri tabanında tüm işlemleri ve her işlem tarafından yapılan veri tabanı değişikliklerini kaydeden bir Transaction Log bulunur, bu değişikliklerin takip edildiği işlem dosyasıdır. Veri tabanının kritik ve önemli bir kısmıdır çünkü tüm bunların loglarda herhangi bir hasar durumunda kurtarma senaryosu aşamasında loglara ihtiyacımız olacaktır.

RECOVERY MODELS

Recovery Modele erişebilmek için ilgili veri tabanına sağ tıklayıp Properties tabından Options page ine tıklayarak erişebiliriz:

   

Resim-1                                   Resim-2

Full Recovery Model

Veri tabanı oluşturulduğu sırada Model veri tabanının da Recovery Modelinin Full olması sebebiyle varsayılan olarak gelen Recovery Model türüdür. Bir veri tabanı Full modda ise bu veri tabanındaki tüm işlemler loglara istisnasız kaydedilir. Full Recovery Modelde Log Backup yedeklemesi gerçekleştiği zaman transaction loglar kesilir yani loglarda yeniden kullanılabilir alan açılır. Örneğin Full Backup alındığında Transaction Log bu şekilde kesilmez. Bu yüzden belirlenen periyotlarda düzenli olarak Transaction Log Backup alınmalıdır. Aksi takdirde transaction log, drive ı dolduracak veya boyut sınırına ulaşana kadar büyüyecektir.

Bu periyotların sıklığına karar verme aşamasında göz önünde bulundurulması gereken iki husus vardır: ‘Ne kadar Transaction alıyoruz?’ ve ‘Ne kadar zamanlık bir kayba tahammülümüz var?’

Full Modelin en büyük avantajı Transaction Log backup alabilme imkanı tanıdığı için örneğin saatte bir Log Backup alınıyorsa herhangi bir hasar durumunda en kötü ihtimalle bir saat öncesine restore şansını bizlere tanır.

Bulk-Logged Recovery Model

Bulk Logged Recovery Model Transaction Log Backup alınmasını Full Recovery Model gibi belli periyotlarla gerektirir. Transaction Log kesmesi açısından Full Model gibi davranır, tüm işlemler loglanır ancak Bulk işlem yapıldığında bu işlemler için tek bir kayıt yazılır. Bulk(toplu) işlemlerin tek bir kayıt halinde yazılması loglarda daha az yer kaplar ve Bulk işlemlerde daha yüksek performansla çalışır. Ancak bir felaket durumunda bulk işlem yapıldığında tüm işlemler için tek bir kayıt log dosyasına yazma özelliği de Full Modelden dezavantajını gösterir çünkü bulk işlemler sırasında oluşabilecek hasar durumunda hasar öncesi zamana restore edebilme imkanı vermez. Full Model bu sebeple daha tercih edilebilir seçenek haline geliyor, yüksek performanslı olması bu riskin oluşundan dolayı özellikle canlı ortamlarda göz ardı edilmektedir.

Simple Recovery Model

Diğer Recovery Modeller gibi, Simple Recovery Modelde de de Transactionlar minimal olarak kaydedilebilir. Ancak bu kayıt aşaması checkpoint işlemine kadardır. Simple Modeldeki temel fark, bir checkpoint tamamlandığında Transaction Logun kesilmesidir. (yeniden kullanılabilir olarak işaretlenen alan) Ancak tümüyle loglara kaydedilen transaction tamamlandığında, loglarda üzerine yazılır. Bu yüzden Simple Modelde log yedeklerini alamıyorsunuz. Loga yazılan işlemlerden herhangi birini kurtarmayı gerekli görmediğimizde tercih edilir.

 Resim-3

Simple Model ile bir veri tabanının Log Backupı alınamayacağından, bu modele sahip bir veri tabanı hasar görürse,restore aşamasında yapılabilecek yöntemler son alınan Full Backup veya Differantial Backup ı geri yüklemektir. Log Backup yedekleri alınamadığından restore u da yapılamaz. Bu aşamada Simple Model, bir veri tabanında felaket durumlarında veri kaybı açısından önemli bir risk olabilir.

Veri tabanı oluşturulduğunda Recovery Modele nasıl karar verileceği aşamasına gelince de veri tabanına zarar veren bir felaket durumunda, Simple Modelde alınabilecek Backup türleri Full ve Diff Backup olacağından ne kadarlık bir kayba tahammülümüz olacağı kararlaştırılmalıdır. Transactionı fazla olmayan veri tabanlarında Simple Model tercih etmek daha doğru bir tercih olacaktır. Genellikle DEV, TEST  ortamlarda ve PROD ortamlarda da çok az miktarda Transactiona sahip  kritik olmayan veri tabanları mevcutsa Simple Recovery Model tercih edilebilir.

Belli periyotlarla gün içinde de birden fazla DIFF alınabilir ya da Full yedeği her gün alınabilir ancak bu noktada maliyetin arttığını gözlemleriz ve bu yedeklemeler arasında gidip backup alınmayan saatlerdeki verilerimizi özellikle Transactionı fazla olan veri tabanımızda kaybetmek istemeyiz.

Bu konuyla ilgili sorularınızı  alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

https://www.mshowto.org

TAGs:SQL Server Recovery Models, Transaction Log, Full Recovery Model, Bulk-Logged Recovey Model, Simple Recovery Model, Checkpoint, Recovery Types

Bu İçeriğe Tepkin Ne Oldu?
  • 36
    harika_
    Harika!!
  • 0
    be_enmedim
    Beğenmedim
  • 2
    _ok_iyi
    Çok iyi
  • 1
    sevdim_
    Sevdim!
  • 0
    bilemedim_
    Bilemedim!
  • 0
    olmad_
    Olmadı!
  • 0
    k_zd_m_
    Kızdım!

Trakya Üniversitesi - Bilgisayar Mühendisliği mezunuyum. Öğrenim hayatım boyunca C, C++, C#, VB.NET ve ASP.NET MVC dilleri ile SQL Server veri tabanı altyapılı çeşitli otomasyon projelerinde yer aldım. İş hayatıma ERP Software Support Specialist pozisyonuyla başlayıp kısa bir süre sonra kariyerime BELBİM Elektronik Para ve Ödeme Hizmetleri A.Ş.'de Ms SQL Database Administrator pozisyonu ile yön vermiş bulunmaktayım. SQL Server ile birlikte Data Warehouse, Oracle ve PostgreSQL alanlarına ilgiliyim ve kendimi bu alanlarda geliştirmeye devam ediyorum.

Yazarın Profili

Bültenimize Katılın

Tıklayın, üyemiz olun ve yeni güncellemelerden haberdar olan ilk kişi siz olun.

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir