MSSQL Server Tail Log Backup

Bu makalede Tail Log Backup konusunu ele almış olacağız. Kısa bir teori bilgiden sonra uygulamalı bir şekilde örneğimize geçelim. Sql server’ın çalıştığı ortamlarda düzenli bir şekilde FULL,DIFF ve LOG backup alınır. Tail log backup ise en son alınan log backup’dan sonra backup alınmamış veritabanının log kayıtlarının fark yedeğini alır. Böylece veri bütünlüğü garanti altına alınmış ve  veri kaybı olmadan son ana rahatlıkla dönebiliriz. Tail log backup log dosyalarının zincir yapısının son halkasıdır.

Tail log backup alındıktan sonra veritabanımız restoring moda geçer. Herhangi bir istek veya kayıt veritabanımıza kaydedilmez. Bu veritabanının restore edilecek yeni ortamında veri kaybı olmadan kayıpsız bir şekilde devam etmesi sağlanır.

Şimdi aşağıda yapacağımız örneğimizde bir job aracılığıyla BACKUP_TABLE tablomuza belirli aralıklarla güncel tarih değeri atılmaktadır. Canlı bir şekilde veri akışının geldiği bu veritabanı başka bir ortama taşınmak istendiğinde ilgili veritabanı  tail log backup yöntemiyle restoring moda alınır. Kısacası veri akışı kesilmiş olur. Daha sonra yeni ortama restoring modda olan veritabanının full,diff ve log backupları norecovery restore edildikten sonra tail log backup recovery modda restore edilerek veritabanımız veri kaybı olmadan  yeni ortamında ayağa kalkmış olur.

İlk başta S2 sunucusunda olan veritabanının full, diff ve log backuplarını yeni ortamım olan S3 sunucusuna yüklüyorum.

Full,Diff ve Log backupları norecovery modda yeni sunucuma restore işlemi gerçekleştirdim. Bu işlemi yapma sebebim tail log backup alacağım veritabanının yeni ortama restore ederken sistemin az kesinti ile yeni ortamda ayağa kalkmasını sağlayacağız. Aşağıdaki kod norecovery restore komutlarım.

USE [master]
RESTORE DATABASE [AdventureWorks2012] FROM  DISK = N'C:\aa\AdventureWorks2012_full.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
RESTORE DATABASE [AdventureWorks2012] FROM  DISK = N'C:\aa\AdventureWorks2012_diff.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
RESTORE LOG [AdventureWorks2012] FROM  DISK = N'C:\aa\AdventureWorks2012_log.trn' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
GO

S2 sunucumda Tail log backup almadan veritabanımızda kaç veri olduğunu gözlemleyelim.

S2 sunucumda veritabanımı tail log backup ile restore moduna alıyorum. Veritabanının üzerine sağ tıklayıp Task>Back Up.. diyiyoruz.

Gelen ekranda Backup Type kısmında Log backup alacağımız için  Transaction Log’u seçiyoruz. Back up to kısmında Disk’i seçtikten sonra Add kısmında tail log backup’ı nereye kaydetmek istiyorsak ilgili path’i seçiyoruz ve uzantısını .trn yapıyoruz.

Bu ayarlamaları yaptıktan sonra Backup Options kısmına gelinir. Gelen ekranda Back up the fail of the log, and leave the database in the restoring state   kısmının tail log backup için işaretlenmesi lazım. Daha sonra yukarıda Script yazan yere tıklayarak işlemin script’i alınır. Bu şekilde alınan tail log backup ile son log dosyası olduğunu garanti altına almış oluyoruz.

Not: Alwayson kullanıyorsanız veritabanını ilgili availability groupdan çıkarmadan tail log backup işlemi gerçekleşmez. İlgili bölüm pasif görülmektedir.

BACKUP LOG [AdventureWorks2012] TO  DISK = N'C:\aa\AdventureWorks2012_Tail_log.trn' WITH  NO_TRUNCATE , NOFORMAT, NOINIT,  
NAME = N'AdventureWorks2012-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  NORECOVERY ,  STATS = 10
GO

NO_TRUNCATE ifadesi hasar görmüş veritabanlarında kullanılır. Bu yüzden kodumu çalıştırmadan çıkarıyorum. ldf dosyası hasar görmüşse log backup alınamadığı durumlarda alınabilir. Veritabanımız Recovery Pending modunda olsaydı bu komut kullanılabilirdi. Bu komutla restore ederken copy-only ifadesi arayüzde görülmektedir. Normalde Log backup alındığında log’un içerisi truncate edilir şişmesin diye copy-only backup alındığı zamanda logun içerisini truncate etmez.

Yukarıdaki komutu çalıştırdığınız hata mesajıyla karşılaşırsanız. Bu hatanın  çözümüyle ilgili BACKUP cannot process database ‘XXX’ because it is in use by this session. makaledini okumalısınız.

Tail log backup’ı aldıktan sonra hemen ikinci sunucumuzda(S3) restore işlemine geçelim. Aşağıdaki resimde veritabanımızın S2 sunucusunda restoring moda düştüğünü görebiliriz.

Not: Yeni ortamda Tail Log Backup yüklenmeden önce FULL,DIFF ve LOG backuplar yüklenir.

Restore işlemine geçmeden önce şunu da belirtmek gerekir ki tail log backup kendinden önceki log backup ile arasında farkı alıyor. Tail log backup alınmasaydı herhangi bir yedek işlemi yapılmamıştı. Bu iki log dosyası arasındaki zaman içinde ne kadar veri gelmişse kaybedilmiş olunacaktı. Aşağıdaki resimde dikkat edebilirsiniz. 1 saatlik gibi bir veri kaybı.

Tail log dosyamı S3 sunucuma kopyalayıp restore işlemine geçiyorum. S3 sunucusunda restoring modun da olan database üzerine sağ tıklayıp Task>Restore>Transaction Log ifadesine tıklıyorum.

Gelen ekranda General sekmesinde From Device kısmında ilgili tail log backup dosyamı seçiyorum.

Dosyamızı seçtikten sonra Options kısmında Restore With Recovery  seçeneğini seçerek veritabanımızı restoring modun dan çıkarıyoruz.

RESTORE LOG [AdventureWorks2012] FROM  DISK = N'C:\a\AdventureWorks2012_Tail_log.trn' WITH  FILE = 1,  NOUNLOAD,  STATS = 10
GO

Şimdi bakalım yeni ortamımıza tail log backup’la restore ettiğimiz veritabanının içindeki tabloda kaç veri var.

Yeni ortamdaki ilgili veritabanındaki tabloya select çektiğimizde  önceki veritabanımızdaki tablodaki verilerin ve sayıların aynı olduğunu görmüş oluyoruz.

Kısacası Tail Log Backup veritabanının Recovery Pending durumunda kalması, veri kaybı olmadan kısa kesinti ile veritabanının ayağa kalkması kısacası veritabanının ulaşılamaz olduğu durumlarda işimize yarayan çok iyi bir yöntem olarak karşımıza çıkmaktadır.

Not: Always on yapılarında veritabanının tail log backup alınmasını sağlamak için veritabanının AG altından çıkarılması gerekmektedir.

Not: Restoring modunda olan veritabanını açmak için aşağıdaki komut kullanılmaktadır.

RESTORE DATABASE DB_NAMEE WITH RECOVERY

Not: Tail log backup alınıp farklı bir ortamda veritabanını restore edildikten sonra(veritabanı ikinci ortamda açıldıktan sonra veri yazma işlemi devam ediyor.) herhangi bir sorun anında yeni ortama alının veritabanı üzerinde tekrardan tail log backup alınıp, alınan bu tail log backup ilk anda alınan ve restoring modunda olan veritabanı üzerine restore edilebilir. Canlı sistemlerde bu yol tercih edilmektedir.

Bu makalede Tail Log Backup nedir ve nasıl kullanılır konusunu ele almış olduk.

Başka bir makalede görüşmek dileğiyle.

“(Ey Muhammed!) Senin göğsünü açıp genişletmedik mi? Belini büken yükünü üzerinden kaldırmadık mı? Senin şânını ve ününü yüceltmedik mi?  Şüphesiz güçlükle beraber bir kolaylık vardır.  Gerçekten, güçlükle beraber bir kolaylık vardır.  Öyleyse, bir işi bitirince diğerine koyul. Ancak Rabbine yönel ve yalvar.” İnşirah