SQL Server Tail Log Backup Nedir ?

Merhabalar,

Yönettiğimiz ya da bir geliştirme yaptığımız uygulama için kullanmış olduğumuz veri tabanı sisteminde, verilerimizin hassasiyetine bağlı olarak bazı bakım planları yapmaktayız. Bu bakım planlarıyla birlikte daha az kaynak kullanarak daha hızlı sonuçlar elde etmeyi hedefliyoruz. Bununla beraber düzenli olarak bakım işlemleri yapılıp, her şey yolundaymış gibi görünse de bazı durumlarda bir anlık dikkatsizlik ya da hazırlanan sorguların beklenmedik yerleri etkilemesi sebebiyle her şey tersine dönebilir.

Konu veri olduğunda ise bu verilerin yapısının bozulması ya da veri kaybolması gibi istenmedik durumlar bir veri tabanında kabul edilemeyecek durumlar arasında ilk sıralarda yer almaktadır. Bu tarz durumların önüne geçmek ve hataları minimalize etmek için belirli periyotlarla yedekler alarak hata anından önceki zamanlara dönebilmekteyiz. Bu yedekler belirli gereksinimler dahilinde planlanarak bir backup zinciri şeklinde alınmaktadır.

Bu yazımızda ise log backupın bir varyasyonu olarak karşımıza çıkan Tail Log Backup’ı inceleyeceğiz.

Tail Log Backup nedir?

Kısaca tanımlamak gerekirse Tail Log Backup, gerçekleşen işlemlerin belirli bir düzende alınan log backup ile henüz yedeklenmemiş kısmının yedeklenmesidir.

Örnek vermek gerekirse, her gün 1 kez Full backup ve her 10 dk da bir Log backup alındığını düşünelim. 13:00 ve 13:10 da log backuplar alınacaktır. Log backupların bir önceki Log backuptan itibaren gerçekleşen işlemleri yedeklediğini biliyoruz. Yani 13:10 da alınan log backup 13:00 ile 13:10 saatleri arasındaki işlemleri yedekler. Fakat 13:06’da bir hatayla karşılaştık ve elimizde en son 13:00’da alınmış bir log backup var. 13:00’da alınmış olan son log backupa dönersek aradaki 6 dakikalık veriyi kaybetmeyi göze mi alacağız ?

Tabi ki böyle bir şey yapmayacağız ve 13:06’da bir tail log backup alacağız. 13:06 da bir tail log backup aldığımızda bu 13:00 ile 13:06 saatleri arasındaki işlemleri yedekleyecektir.

Bu noktada bir soru gelebilir aklımıza. Neden 13:06’da manuel olarak kendimiz Log backup değil de Tail log backup almayı tercih edelim ?

Burada biraz Tail log backup detaylarına girelim ve cevap arayalım.

Log backup ve Tail log backup temelde aynı işlevi görmektedir. İki backup çeşidi de alınmış olan son log backuptan itibaren gerçekleşen işlemleri yedekler. Yani Tail log backup için, log backup yapısının bir özel çeşidi ya da özel çözümü diyebiliriz.

Data kaybını önlemek ve backup zincirini kırmamak için tercih edeceğimiz Tail log backup, bize gerçekleşmiş olan son işlemin yedeklendiğini garanti etmektedir. Bunu da yazımızın devamında alacağımız Tail log backup sonrası veri tabanının “Restoring” moda geçtiğinde göreceğiz.

Şimdi yukarıdaki sorumuza cevap aramaya devam edelim.

Tail Log Backup tercih edeceğimiz bazı istisnai durumlar mevcuttur. Bu durumlar dışında Tail Log Backuplar periyodik olarak alınmaz, yedekleme stratejilerine dahil edilmez. Kullanıcı bu işlemi kendisi gerçekleştirir.

Bu durumlardan birisi olarak karşımıza veri tabanı bozulmaları çıkmaktadır. Böyle bir durumla karşılaşmamızın altında yatan genel sebep ise I/O ‘dan kaynaklanan sebeplerdir.

Eğer veri tabanında bozulma yaşanmışsa, log backup alınması sırasında hata ile karşılaşabilirsiniz. Böyle bir durumda log dosyaları bozulmamışsa(başka değişkenlere de bağlı olarak), WITH CONTINUE_AFTER_ERROR seçeneğini kullanarak tail log backup deneyebiliriz. Yukarıdaki sorumuzun ilk cevabı olarak da bunu verebiliriz.

Bir başka sebep olarak -ki en çok kullanım alanı olarak karşımıza çıkmaktadır- bir sorun yaşadığımızda restore işlemi gerçekleştirirken data kaybını önlemek amacıyla ihtiyaç duyabileceğimiz durumları örnek verebiliriz.

Örneğin, veri tabanımız online durumda, dolayısıyla sorgular geliyor ve kayıtlarda değişiklikler yaşanıyor. Böyle bir durumda servisleri durdurarak pire için yorganı yakmaya gerek yok. Log backup joblarını durdurup, veri tabanını read only’e çektikten sonra son kez manuel olarak log backup da alabileceğimiz gibi bu yazımızın konusu olan tail log backup alarak sadece o veri tabanında işlemleri kısıtlayabiliriz.

Backup işlemi tamamlandığında veri tabanı “Restoring” moda geçer. Bu dakikadan sonra ilgili veri tabanında bir işlem gerçekleştiremeyeceğimiz için aldığımız tail log backup, gerçekleşmiş son işlemi de kapsayacak şekilde alınmış bir yedek olacak ve hemen ardından Restoring moda geçtiği için üzerine başka değişiklik olmayacaktır. Bu kapsamda data kaybını önlemiş oluruz. Sonrasında ise gerekli log restore işlemlerini tamamlayarak çalışmayı herhangi bir veri kaybı olmadan sonuca bağlayabiliriz.

Uygulamaya geçmeden önce hatırlatmakta fayda görüyorum. Tail log backup için log backupın bir varyasyonu demiştik. Bu sebeple Log backup alabilmek için dolayısıyla da Tail log backup alabilmek için veri tabanımızın recovery modeli FULL olmalıdır.

Şimdi SSMS üzerinden tail log backup nasıl alınır onu inceleyelim.

Veri tabanına sağ tıklayıp Task –> Backup diyerek ilgili menüyü açıyoruz.

Daha sonra açılan menüde Backup type kısmını Transaction Log seçiyoruz. Copy-only Backup seçeneğini de işaretledikten sonra backup dosyasının kaydedileceği yolu belirtiyoruz.

Media Options bölümüne geçiyoruz. Aşağıdaki gibi Transaction Log bölümünde yer alan işaretli yeri seçiyoruz. Bu işlemi script yardımıyla almak, backup parametre tercihlerini değiştirmek ya da çıkarmak isterseniz yukarıda yer alan script bölümüne tıklayarak da işlemi tamamlayabilirsiniz.

OK dedikten sonra tail log backup alınacak ve veri tabanımız Restoring moduna geçiş yapacaktır. Kontrol etmek amacıyla query yazmak için use komutunu kullanmak istediğimizde ise aşağıdaki gibi hata alıyoruz.

Bu noktada iki yol izleyebiliriz. Eğer bir hatadan dolayı ya da başka bir sebeple restore işlemi gerçekleştireceksek;

1. Full backup restore etmek.(WITH REPLACE ve NORECOVERY seçeneği ile)
2. Log backupları restore etmek(NORECOVERY seçeneği ile devam ediyoruz.)
3. En son almış olduğumuz Tail log backup restore etmek.(Artık son backupı döneceğimiz için NORECOVERY değil RECOVERY seçebiliriz.)

Bu seçeneklerin ardından veri tabanımızda Tail log backupı döndük ve son backupı RECOVERY seçeneği ile restore ettikten sonra Restoring moddan çıktığını görmüş olduk. Bütün bu adımlarda Tail log backup aldığımız adımdan, son restore işlemine kadar veri tabanımız Restoring modunda kaldı ve herhangi bir veri kaybı yaşamadık.

Eğer bir restore işlemi gerçekleştirmek değil de başka sebeplerle tail log backupa ihtiyacımız varsa aşağıdaki scripti çalıştırarak veri tabanını Restoring moddan çıkarabiliriz.

RESTORE DATABASE [AdventureWorks2019] WITH RECOVERY

İlave olarak, bir restore işlemi gerçekleştireceğiniz zaman da size seçenek olarak restore işleminden önce tail log backup almak için seçenek sunmaktadır. Bu seçenek aslında bir ipucu niteliğindedir. Son log backuptan sonra değişen birtakım işlemler olabileceğine dair uyarı gibi görebilirsiniz.

Restore işlemi gerçekleştirirken de alabileceğiniz tail log backup sonrası veri tabanı benzer şekilde Restoring moda geçeceğinden dolayı yukarıdaki aynı durumlar geçerli olacaktır. İhtiyaç duyulan full + log restore işlemlerini yaptıktan sonra tail log backup için de recovery seçeneği ile restore işlemi gerçekleştirip işlemi tamamlayabilirsiniz.

Elinizde olan bir full backuptan ismini değiştirip kopya bir database oluşturmak istediğinizi düşünelim. Eğer 2.seçeneği seçerseniz, full backup alınmış kaynak database i de Restoring moda sokacaktır. Dikkat etmekte fayda var. 1 numaralı seçenek ise restore işlemiyle birlikte tail log backup da alacaktır.

Umarım faydalı bir yazı olmuştur.

Bir başka yazıda görüşmek üzere.

Hoşça kalın.