Veritabanı recovery modelleri
Recovery model transactionların nasıl loglanacağını kontrol eden bir veritabanı özelliğidir. Recovery Model’e göre bazı high availability seçenekleri kullanabilir ya da kullanamazsınız, bazı backup tiplerini alabilir ya da alamazsınız.
3 tip recovery model vardır.
- Full Recovery Model
- Simple Recovery Model
- Bulk Logged Recovery Model
Full Recovery Model: Bütün transactionların loglandığı modeldir. Veri kaybına tahammülünüz yoksa kesinlikle bu Recovery Model’i kullanmalısınız. Production ortamlarda kullanılması gerekir. Log Backup alınabilir ve gerçek zamanlı restore yapılabilir.
Örneğin Cuma gecesi Full Backup aldınız, Çarşamba gecesi Differential Backup aldınız ve 2 saatte bir de Log Backup alıyorsunuz. Ve Perşembe günü sabah 08:10’da bir sıkıntı oldu. Uygulamacılar sizden en son yedeği yüklemenizi istiyorlar. Sırasıyla önce Full Backup’ı, sonra Differential Backup’ı, sonrasında da Differential Backup’tan sonra alınan tüm Log Backup’ları sırayla Perşembe 08:00’e kadar restore etmeniz gerekiyor. Bu şekilde son ana kadar dönebilirsiniz.
Full Recovery Model kullanıyorsanız mutlaka log backup almalısınız. Eğer log backup almazsanız yapılan bütün işlemler loglandığı ve otomatik olarak silinmediği için bir süre sonra diskinizi dolduracaktır. Log Backup aldığınızda transaction log dosyasında kaydedilen bu loglar silineceği için aşırı büyümesini engellenecektir.(Logların silinmesi korkutucu gelmiş olabilir. Bu silinme işlemi endişe edilecek bir durum değildir. Aksine yapılması zorunlu bir işlemdir. Aldığınız log backup’ta bu veriler mevcuttur. Herhangi bir sorun anında bu Log Backup dosyalarını kullanarak yukarda anlattığım gibi istediğiniz ana dönebilirsiniz. ) Hangi sıklıkla log backup alacağınız kurumunuzun politikası ile alakalıdır. Genellikle önemli ve büyük uygulamalarda 2 saatte bir alınır.
Simple Recovery Model: Bütün transactionlar loglanır fakat SQL Server’da checkpoint işlemi gerçekleştiğinde loglanan bu transactionlar otomatik olarak silinir ve transaction log dosyası genelde büyümez. “Database Checkpoint Nedir” isimli makalemi okumanızı tavsiye ederim. Genelde ifadesini kullanıyorum çünkü bazen tek transaction log dosyasının boyutunu çok büyütebilir. Bu şekilde büyük bir transaction gelirse SQL Server Log dosyasını transaction bittikten sonra shrink edebilirsiniz. “SQL Server Log Dosyasını Shrink Etmek” isimli makaleme göz atabilirsiniz. Log backup alınamaz.
Log Backup alınamayacağı için yukarıdaki örneğimizdeki gibi bir durumla karşılaşırsak Perşembe günü sabah 08:00′ e dönmemiz söz konusu olmayacaktır. En yakın tarih olarak Çarşamba gecesi alınmış Differential Backup’a dönebileceğiz.
Genellikle test ve geliştirme ortamlarında kullanmanızı tavsiye ederim.
Always ON, Database Mirroring ve Log Shipping’i desteklemez.
Bulk Logged Recovery Model: Genelde tercih etmediğim recovery modeldir. Full Recovery Model’den farklı olarak
SELECT INTO, BULK INSERT, BCP, CREATE INDEX gibi Bulk işlemlerin tamamı loglanmaz. Bu şekilde bulk işlemlerin yoğun olduğu veritabanlarında transaction log dosyasının çok büyümesi engellenmiş olur.
Genelde tercih etmiyorum çünkü,
Log Backup alınabiliyor fakat,eğer son log backup’ta bulk işlem ile ilgili bir kayıt varsa restore yapılamıyor. Bulk Logged Recovery Mode’i sadece geçici olarak kullanabilirsiniz. Örneğin Full Recovery Model’i kullanıyorsunuz ve büyük bir bulk işlem yığını yapacaksınız ve diskinizde yeterli yer yok. Veritabanı Recovery Model’ini Bulk Logged yapıp işleminiz bitince tekrar Full’e çekebilirsiniz. “Veritabanı Recovery Model’ini Değiştirmek” isimli makaleme göz atmak isteyebilirsiniz.
