SQL Server’da veri güvenliği, geri dönüş stratejileri ve disk kullanımı yönetimi açısından oldukça önemli bir yapı olan Recovery Model (Kurtarma Modeli), veritabanının nasıl yedeklendiğini ve verilerin nasıl kurtarılabileceğini belirler.
Bu makalede, SQL Server’ın sunduğu üç temel recovery modelini detaylı bir şekilde inceleyeceğiz:
- Simple Recovery Model
- Full Recovery Model
- Bulk-Logged Recovery Model
Recovery Model, SQL Server’da veritabanının transaction log davranışını belirleyen sistemsel bir ayardır. Bu ayar sayesinde:
- Ne kadar veri kaybına tolerans gösterileceği,
- Hangi yedekleme stratejilerinin uygulanabileceği,
- Veritabanının ne kadar hızlı kurtarılabileceği gibi konulara karar verilir.
İlgili database üzerine sağ tıklayıp properties kısmında bulunan options bölümünden recovery model’i görebiliriz.
Şimdi bu kavramların ne olduğunu açıklayalım
Simple Recovery Model: Veritabanı seviyesinde yapılan her işlemler loglanır. Kaydedilen loglar checkpoint işlemi sırasında otomatik olarak silinmektedir. Bu modelde data kaybı riski oluşmaktadır. Kaydedilen veri mdf’e yazılmadan silinme ihtimali vardır. Kullanacağımız verinin herhangi bir önemi yoksa recovery model’i yapılabilir. Bu model yapısında transaction log backup yoktur. Simple yapısında olan databaselerde full backup ve diff backup yapısı tek vardır. Simple Recovery Model’i program geliştiriciler, veritabanı test edenler, Günde 1 kez yedeklemenin yeterli olduğu sistemlerde, Log yedeği takibi yapmak istemeyenlerde için en uygun modeldir.
Yalnızca tam (full) ve diferansiyel (diff) yedek alınabilir. Transaction log dosyası otomatik olarak küçülür. Daha az disk alanı kullanır, daha az yönetim gerektirir. Sadece son yedekleme noktasına kadar kurtarma yapılabilir.
Data kaybı riski olmasının sebebi checkpoint işlemi gerçekleşmeden sunucunun kapanması veya herhangi bir sebepten dolayı veri kaybı olmaktadır. Normalde veriler WAL prensibi ile önce ldf dosyasına commit edilir. bufferda bulunan dirty pagelerin mdf veya ndf diskine yazılması için checkpoint işlemi gerçekleşti bu esnada log dosyası truncate edilir. Ama veriler mdf-ndf diskine yazılmadan sunucu çökerse veri kaybı olmaktadır.
High availability seçeneklerinde AlwaysOn Log Shipping Database Mirroring için desteklenmez.
Recovery Model Değiştirme Komutu:
ALTER DATABASE VeritabaniAdi SET RECOVERY SIMPLE;Bulk-Logged Recovery Model:Bu modelde transaction log backup sql server tarafında desteklenir. Simple recovery modelde olduğu gibi loglar otomatik olarak silinmez. Bu yapıda toplu bir insert geldiğinde log dosyasının şişmesinin önüne geçer sadece tek bir satırda bulk insert yapıldığı bilgisi geçmektedir. Kısacası Bulk-Logged recovery model’de bulk operasyonlarını minimum düzeyde loglayarak transaction log’ların alan kullanımı azaltır. Bu yapının önündeki en büyük sorun son log backupta bulk işlemi ile ilgili bir kayıt varsa restore işlemi yapılamıyor. Full Recovery Model’den farklı olarak SELECT INTO, BULK INSERT, BCP, CREATE INDEX gibi Bulk işlemlerin tamamı loglanmaz.
Veritabanına herhangi bir bulk işlemi yapacaksak recovery model full den bulk-logged’a çekilebilir.
Recovery Model Değiştirme Komutu:
ALTER DATABASE VeritabaniAdi SET RECOVERY BULK_LOGGED;Transaction log yedeği alınabilir, ancak bulk işlemler sırasında point-in-time recovery mümkün değildir.
Full recovery modelden Bulk logged moda gelirse log backup işlemlerimiz devam etmektedir.
Not: Index rebuild işlemi sırasında transaction log dosyasının şişmesi SQL Server’da sık karşılaşılan bir durumdur. Bunun temel nedenleri: Full/Bulk-Logged Recovery Model modlarda index rebuild işlemleri tamamen loglanır. Simple recovery model daha az log üretir, ancak log otomatik olarak truncate edilir. Bu yapıya geçildiğinde log zincirimiz bozulmaktadır. Index rebuild işlemi aslında eski indexi silip yenisini oluşturur. Tüm veri sayfaları yeniden yazılır. Her değişiklik transaction log’a kaydedilir. Online Rebuild: Daha fazla log üretir (kullanıcı erişimine izin verirken ek bilgi tutar) Offline Rebuild: Nispeten daha az log üretir. Minimal loglama tercih edilmesi isteniyor aynı zamanda log zinciri devam edilmesi isteniyorsa Bulk loged recovery modele geçiş yapılır. Tabi bu işlem stand alone veritabanları için geçerlidir. AlwaysOn veritabanlarında veritabanı Full recovery modelde olmak zorundadır.
Bulk-Logged Mode’da Log Backup Davranışı
- Normalde Hata Oluşmaz:
- Standart log backup işlemleri çoğunlukla hatasız çalışır
- Backup işlemi minimal logging ile yapılan operasyonları da içerecektir
- Potansiyel Riskler:
- Bazı durumlarda backup tam restore edilemeyebilir: Eğer bulk işlemler sırasında database hasar görürse
- Point-in-time recovery sınırlamaları: Bulk işlemlerin olduğu noktalarda tam zamanlı kurtarma yapılamayabilir
Full Recovery Model: Bu modelde yapılan her işlemler log dosyasına yazılmaktadır. Data kaybı bu modelde mümkün değildir. Bu recovery modelde her şey log dosyasına yazıldığı için log dosyamız bir süre sonra şişmektedir. Bu sorunun önüne geçmek için belirli aralıklarla log backup alınması lazım. Log backup alındığı zaman log dosyamız otomatik olarak silinmektedir. Truncate olan log dosyamızın içerisinde bulunan sanal log dosyaları(vlf) in-active olarak işaretlenir. Tekrar veriler geldiğinde üzerine yazılsın diye. Bu yapıda kısacası log dosyası backup alınıp truncate edilir daha sonra tekrardan kullanılabilir duruma gelmektedir.
Hatalı işlemler veya çökme durumunda belirli bir zaman noktasına kadar kurtarma (point-in-time recovery) mümkündür. Diğer iki recovery modelle mümkün değildir.
High availability seçeneklerinde AlwaysOn Log Shipping Database Mirroring için olmazsa olmazımızdır. AlwaysOn sekmesinde recovery model full değilse herhangi bir işleme yapamıyoruz.
Recovery Model Değiştirme Komutu:
ALTER DATABASE VeritabaniAdi SET RECOVERY FULL;Recovery model’i değiştirmek istediğimizde veritabanı üzerine sağ tıklayıp properties kısmına tıkladığımızda karşımıza gelen options ekranında full olan veritabanının recovery model’ini simple olarak değiştirebiliriz.
Yukarıdaki resimde görünen recovery model kısmından simple seçilipte yapılabilir, create scriptide alınıp yapılabilir.
USE [master]
GO
ALTER DATABASE [TEST23] SET RECOVERY SIMPLE WITH NO_WAIT
GOAyrıca veritabanının recovery modelini properties options kısmındanda girmeyip database üzerinde F7 tuşuna basarak öğrenebiliriz.
Not: Recovery Model’i simple olarak değiştirdikten tekrardan full recovery model yapıp log backup almak istiyorsak full backup almamız gerektiğine dair sistem bizi uyarır.
Not: Bazen kullanıcılar log dosyasının dolmasından dolayı recovery modeli full’dan simple moda çekip daha sonra tekrardan full moduna çekmek isterler. Log dosyasının boşalması için bu işlemi yaparlar. Bu durum eğer düzenli bir log backup mekanizması varsa bozulmasına sebep olacaktır. Tekrar full backup’a aldığınızda log backup almaz sizden önce tekrardan full backup almanıza dair bir hata mesajı verecektir. Aşağıdaki resimde yapılan bu işlem sonrasında alınmaya çalışılan log backup ekranı.
Not: Full recovery modelden Bulk loged recovery modele geçildikten sonra log zinciri kopmaz. Log backup tekrardan alınmaktadır. Index rebuild işlemlerinde kullanılabilir. Dikkatli olunması gerekmektedir.
Not: AlwaysOn yapısında olan bir veritabanının recovery model simple veya bulk-loged recovery modele döndürülemez. Çünkü yapılan her işlemin loglanması gerekmektedir. Secondary sunucusu bu loglar üzerinden yaşamaktadır.
Not: AlwaysOn yapılarında bir veritabanının autogrowth değeri değiştirilirse otomatik olarak secondary sunucusundaki değerde değişmektedir. Ama master-model ve diğer sistem veritabanları birinde yapılan değişiklik diğerinde senkron olmaz.
Bu makalede sql server transactionların nasıl loglanacağını kontrol eden veritabanı seviyesinde recovery model özelliğini ele aldık.
Başka makalede görüşmek dileğiyle..
Allah bütün canlıları sudan yarattı. İşte bunlardan bir kısmı karnı üzerinde sürünür, kimi iki ayak üzerinde yürür, kimisi dört ayak üzerinde yürür. Allah dilediğini yaratır. Çünkü Allah her şeye hakkıyla gücü yetendir. Nûr -44
