1. Anasayfa
  2. SQL Server

SQL Server’da Veritabanı Yedekleme Stratejileri Nelerdir?


1

Yedekleme stratejilerine giriş yapmadan önce kendinize şu soruyu sorun : Veritabanım ne kadar sıklıkla güncelleniyor? Sorduysanız başlayalım.

Uygun bir yedekleme planı oluşturmak için soru seti sayısı oldukça fazlaca arttırılabilir. Fakat soruların içeriği Veritabanı ve ilgili verilerin taşıdığı önemi, son yedeklemeden sonra ne miktarda veri kaybına tahammül edilebileceği ve ya Veritabanının büyüklüğünü hedef alarak sorgulayacak ise artık günümüzde geliştirilen uygulamaların içerik olarak zenginliği, işlem hacmi, firma için taşıdıkları değer ve herhangi bir veri kaybı durumunda yaşanılacak zaman ve emek kaybı düne göre fazla olduğu için eskiden olduğu kadar yedekleme öncesinde uzun uzadıya tartışmaya değer konular olduğunu sanmıyorum. Çünkü aslında yukarıdaki soruya verilecek cevap bir bakıma yedekleme planını ortaya koymak için ana kriterlerleri sorgulayacak olan diğer tüm soruların da yanıtını içerisinde barındırıyor olacaktır. Özellikle de OLTP (Online Transaction Processing) tipinde Veritabanları için. Peki OLTP nedir?

OLTP, birçok kullanıcı tarafından sürekli ve eşzamanlı olarak veri girişi, verilere anlık erişim ve veri değiş-tokuşu gerektiren işlem (transaction) odaklı uygulamalar tarafından kullanılan Veritabanı türüdür. B2B ve B2C olmak üzere tüm e-ticaret sistemleri, online internet bankacılığı, havayolu ve ya turizm portalları gibi ödeme işlemleri, stok bilgisi değiş tokuşu, online rezervasyon gibi  anlık verilerin işlendiği tüm uygulama altyapılarının kullanmak durumunda olduğu teknolojidir.

Yedekleme stratejisi belirleme ve bu doğrultuda bir an önce harekete geçmek aslında kolay bir konu olmasına rağmen belkide en çok ihmal edilen ve ya oluşturulurken en çok yanlış yapılan süreçlerden bir tanesidir. Bu uygulamada, bir üretim sunucusunda bulunan farklı uygulamalara ilişkin OLTP Veritabanlarını yedeklemek için nasıl bir yol izlenebileceğini adım adım ve mümkün olduğunca detaylı ele alıyor olacağız.

Sürekli olarak erişilen ve güncellenen OLTP Veritabanları için sadece düzenli olarak Full Backup alınması kafi değildir. Eğer Full Backup ile yetinilirse son yedekleme sonrasında gerçekleşmiş tüm işlemlerin tekrar girilmesi gerekecektir ki işlem yoğunluğu bulunan ve birden fazla uygulamanın birbiriyle etkileşerek aynı Veritabanlarını güncellediği profesyonel altyapılarda bu neredeyse imkansızdır. Full, Differential ve Transaction Log yedeklemeleri kombinasyonu iyi bir çözüm olacaktır. Bu yedekleme tiplerine kısaca değinelim;

Full Backup: Veritabanının bütünüyle kopyasını tek bir yedekleme dosyasına alır. Yedekleme stratejisine neredeyse her zaman Full Backup ile başlangıç yapılır ve yedekleme zincirinde kendisinden sonra alınacak Differential(değişen) yedekleri etkilemektedir.

Differential Backup: Son Full Backup gerçekleştiği andan itibaren değişen verilerin yedeğini alır. Bu nedenle gerçekleştirilebilmesi için önce Full Backup alınmış olması gerekir. Genel olarak Full yedeklerden daha küçük olacakları ve daha az sürede ve süratli alınabildikleri için Full yedekleme sonrasında periodik olarak çalıştırmaya yöneliktirler ve Differential (fark) yedeklerinin yedekleme zinciri üzerinde herhangi bir etkisi bulunmamaktadır.

Transaction Log Backup: Son transaction log yedeğinin alındığı andan itibaren Veritabanında gerçekleşen tüm işlemlerin (transactions) yedeğini alır. Transaction Log yedeğinin alınabilmesi için önce bir Full yedek alınmış olması gereklidir. Transactin Log yedekleri Veritabanı işlemlerine ilişkin zaman içerisinde dönülebilecek bir nokta sunuyor olacaktır. Bu özellikle hatalı ve ya problem teşkil eden veri giriş çıkışlarına yönelik anlık geri dönülebilirlik imkanı sunar. Her log yedeğinden sonra varsayılan olarak sanal log dosyaları üzerindeki işlenmiş log kayıtları silinir ve doğal olarak bir sonraki log yedeği kendinden önceki log yedeğinden sonraki işlenmiş log kayıtlarını barındırır.

Uygulamamızda da kullanacağımız Transaction Log yedeklemesi, herhangi bir Veritabanı için ancak Full Recovery Model etkinleştirildiğinde mümkün olabilir. Aksi taktirde Simple Recovery Model ile Transaction Log yedeklemesi yapılamaz.

Bir yedekleme stratejisinin en önemli özelliği bütünlüğüdür. Yani her yedek gerektiği zaman dönülebilir olmalı ve yedekleme zincirini bozmamalıdır. Örneğin elimizde yüz adet log yedeğimiz olsun. Onuncu yedek dosyasının bozulması durumunda kendini takip eden doksan yedek dosyası işe yaramaz hale gelecektir. Böyle bir durumla karşılaşmamak için yedek dosyaları arşivlenmeden önce muhakkak doğrulanmalıdır. (restore verifyonly)

Şimdi yukarıda bahsettiklerim doğrultusunda bir örnek yedekleme planı çıkaralım. Yedekleme sürelerinin kısaltılması ve yedek dosyalarının boyutlarının düşürülmesi açısından Full ve Differential (fark) Veritabanı  yedeklerini kurgulamaya başlayalım.

Full yedekler haftalık periyotlarda Differential (fark) yedekler ise Full yedeklerin alınmadığı günler günlük periyotlarda alınabilir. Bu kurguda ikinci gün alınan Differential (fark) yedek ile yedinci gün alınan diffrential yedek arasında boyut farkı olacağını unutmamak gerekir. Bunun nedeni her Differential (fark) yedeğin en son alınan  Full yedekten sonra yapılan değişiklikleri içermesidir.

Geri dönüş esnasında ise bir Differential (fark) yedek bir Full yedeğe bağlıdır. Yani Differential (fark) yedeğin dönülebilmesi için ilk olarak Full yedek dönülmelidir.Bu durumda verilen örnek için ikinci güne geri dönüş esnasında Full yedek + ikinci gün Differential (fark) yedeği, üçüncü güne geri dönüş esnasında Full yedek + üçüncü gün Differential (fark) yedeği kullanılmalıdır.

Differential (fark) yedek tanımını düşünürsek plansız aldığımız Full yedekler, Differential (fark) yedek zincirinin bozulmasına neden olurlar.

Varsayılan yedekleme seçenekleri ile plansız alınan bir Full Backup alınması durumunda beş,altı ve yedinci günlerde alınacak Differential (fark) yedekler değişecektir ve geridönme ihtiyacında bu yedeğede ihtiyaç duyulacaktır. Düzensiz zamanlarda Full yedek alınması istendiği zaman Differential (fark) yedek zincirini bozmamak için COPY_ONLY özelliği  ile yedek alınmalıdır. COPY_ONLY özelliği Full yedek alırken Veritabanı dosyalarının değişim tabanlı log sıra numaralarını değiştirmeyecektir ve yedekleme değişmesine neden olmayacaktır, aynı özellik log yedeği alırken yedeklenen işlenmiş log kayıtlarının silinmemesini sağlar, varsayılan özelliklerle log yedeği alındığı zaman sanal log dosyalarının içindeki işlenmiş log kayıtları silineceğine daha önce değinmiştik.

Şimdi gelelim log yedeklerimiz için nasıl bir yedekleme strajejisi belirlememiz gerektiğine.Düzenli log yedeği almanın yedek almak dışında amaçlarıda vardır. Başlıca nedenlerden birisi log dosyasının gereksiz yere büyümesini engellemektir. Log yedeği alınırken varsayılan özellik logu yedeklenen Veritabanının sanal log dosyası içerisindeki işlenmiş log kayıtlarının silinmesidir. Bizlerin veritabını tanımlama esnasında belirlediğimiz log için mevcut olan ldf dosyası aslında birden fazla sanal log dosyasından oluşmaktadır ve bu sanal log dosyaları dolduğunda SQL Server yeni bir sanal log dosyası oluşturur. Bu  durum disk seviyesinde log dosyasının büyümesi olarak gerçekleşir. Bu nedenlerden dolayı log yedeklerinin hangi sıklıkla yedekleneceğini belirlemeden önce log kullanımı gözlemlemek gerekir. Bu amaç için DBCC SQLPERF(logspace) komutu kullanılarak log kullanım yüzdeleri incelenebilir.

İyi tasarlanmış bir log yedek stratejisi sonucu log dosyaları büyümemelidir. Eğer ki log dosyası çok sık büyüme eğilimi gösteriyorsa log yedeklerinin frekansları azaltılarak daha sık aralıklarla log yedeği alınması gerekebilir. Bir log yedeğinin içeriğinde kendinden önce alınan log yedeğinden sonra gerçekleşen işlenmiş log işlemleri bulunur. Dolayısıyla istenilen bir ana dönmek için o ana gelene kadarki tüm log yedekleri sırası ile dönülmelidir. Bundan ötürü log yedeklerinin doğrulanarak güvenli ortamlarda saklanması çok önemlidir

Şimdiye kadar yedekleme tiplerinden ve yedekleme stratejilerini geliştirirken nelere dikkat edilmesi gerektiğinden bahsettik. Şimdi ise Veritabanı yedekleme işlemini örneklerle detaylandırmaya çalışalım.

Veritabanı ve Veritabanı loglarının yedeklenmesi “BACKUP” komutu temelinde gerçekleşir. Backup komutunun en temel kullanım notasyonu aşağıdaki gibidir.


Resim-1

Yukarıdaki komutun çalışması durumunda belirtilen Veritabanının yedeği diskte belirtilen lokasyona yedeklenir. Bu komut ile alınan yedek Full yedek tipinde bir yedektir.

Şimdi örneklerimiz için bir Veritabanı oluşturalım ve log yedek alabilmek için bu Veritabanının recovery durumunu Full olarak set edelim.


Resim-2

Differential (fark) yedekleri Veritabanındaki değişiklikleri LSN (Log Sequence Number – Log Sıra Numarası) ile takip eder ve bu bilgi de her Full yedekten sonra ilgili sistem tablolarına yazılır. Bu bilgiye aşağıdaki information schemaya sorgu çekerek ulaşabiliriz.


Resim-3

Henüz yedek almadığımız için yukarıdaki sorgunun sonucu null olarak gelecektir. İlk Full yedeğimizi alalım ve alınan Full yedek hakkında bazı incelemeler yapalım.


Resim-4

BACKUP DATABASE BACKUPTESTDB TO DISK=’D:\\BACKUPTESTFULL_FULL1.BAK’

Yukarıdaki komutun çalışması ile beraber aşağıdaki şekilde sonuçlar alınır. Peki bize bu sonuçlar neler ifade etmektedir?


Resim-5

Yukarıdaki istatistiksel çıktı yedek işlemi esnasında ne kadarlık bir iş yapıldığını (330 Veritabanı sayfası işlenmiş) , işlemin ne kadar sürdüğünü (0.018  saniyede yedekleme süreci tamamlanmış) ve yedek dosyasının diske yazılma hızı (saniyede 143.174 MB) hakkında bilgi verir.

İlk yedeğimizin tamamlanması ile birlikte aşağıdaki sorguyu çekmemiz durumunda Veritabanımız için bir değişim tabanlı log sıra numarası üretildiğini görürüz.


Resim-6


Resim-7

SQL Server bu LSN (Log Sequence Number – Log Sıra Numarası) değerini daha sonra alınan Differential (fark) yedekleri için kullanacak. Şimdi bir Differential yedek alalım ve bu durumu gözlemleyelim. Differential (fark) yedeği Veritabanı yedekleme işleminin bir özelliği olduğundan dolayı özel bir komut seti bulunmaz. Differential yedek almak için gerekli örnek komutumuz aşağıdaki gibidir.

1    BACKUP DATABASE BACKUPTESTDB TO DISK=’D:\\BACKUPTESTFULL_FULL1.BAK’ WITH DIFFERENTIAL

Şimdi fark oluşturmak için örnek amaçlı oluşturduğumuz DB’ye tablo oluşturuyor ve rast gele kayıt atıyoruz.


Resim-8

Şimdi Differential Backup alıyoruz ;

1    BACKUP DATABASE BACKUPTESTDB TO DISK=’D:\\BACKUPTESTFULL_DIFF1.BAK’ WITH DIFFERENTIAL


Resim-9

Şimdi de restore headeronly komutu ile Differential (fark) yedeğin başlık bilgilerini görelim, burdaki amacım Differential (fark) yedeğin log sıra numarasının Full yedeği takip edip etmediğini görebilmemizdir.


Resim-10

Resimden göründüğü üzere LSN numaraları birbirleri ile aynı.Yani Alınan Differential Backup Full Backupın devamı niteliğinde. Şimdi yeni bir Differential (fark) yedeği alıp ikinci Differential (fark) yedeğin birinci Differential (fark) yedeği kapsadığını görelim. Yedeği almadan önce Veritabanı üzerinde biraz daha işlem yaratalım.

Yeni Kayıt Eklemek için ;


Resim-11


Resim-11

Alınan Farkların çıktıları karşılaştırılacak olursa Full yedekten sonra Veritabanı sayfalarının sayısı arttıkça Differential (fark) yedek almak için işlenen Veritabanı sayfa sayısı artıyor ve süre uzuyor.

Şimdi ise daha önce bahsettiğimiz gibi plansız bir şekilde alınan bir Backup’ın bizim LSN değerini nasıl değiştirdiğini görelim. Bu işlem için öncelikli olarak bir Backup alıyoruz.

1BACKUP DATABASE BACKUPTESTDB TO DISK=’D:\\BACKUPTESTFULL_FULL2.BAK’

 


Resim-12

Tekrar kayıt ekliyoruz ;


Resim-13


Resim-14

Sonuçtan görüldüğü gibi Full yedekten sonra Differential (fark) yedeği daha az sayfanın işlenmesine neden oldu, şimdi Differential (yedekteki) DatabaseBackupLSN değerlerinin değiştiğini görelim

Restore headeronly ile başlık bilgisi görüntülemek için;

1RESTORE HEADERONLY FROM DISK =’D:\BACKUPTESTFULL_DIFF3.BAK’


Resim-15

Plansız bir Backup işleminin nasıl bizim LSN değerini değiştirmediğini gösterecek bir uygulama daha yapalım sizler ile.

Bu işlem için tekrar DB üzerinde işlem yapıyoruz ve kayıt ekliyoruz.


Resim-16

Şimdi tekrar kontrol ettiğimizde LSN değerinin değişmediğini dolayısıyla yedekleme zincirinde herhangi bir sorun olmadığı gözlemlemiş oluyoruz.

Log yedeklerinde ise durum Differential (fark) yedeklerinden farklıdır. Log yedekleri Veritabanı log dosyaları içinde barınan işlenmiş log kayıtlarının yedeklenmesini sağlayacağını  ve log yedeğinden sonra varsayılan olarak işlenmiş log kayıtlarını sileceğinden bahsetmiştik. Bu bahsedilenleri örneklerimizle görelim.

1    BACKUP LOG BACKUPTESTDB TO DISK=’D:\BACKUPTESTDB_LOG1.TRN’


Resim-17

Log dosyasını incelemeye başlıyoruz;

1    RESTORE HEADERONLY FROM DISK=’D:\BACKUPTESTDB_LOG1.TRN’


Resim-18

Log yedek dosyasını incelediğimizde yedeklenen işlenmiş log kayıtlarının belirli aralıkta olduğunu görüyoruz. Log yedekleri tamamen sıralı yedeklerdir. Bir sonraki seferde alınacak  log yedeği bu yedekteki Last LSN den başlayacaktır. Bunu gözlemlemek için aşağıdaki komutu kullanılarak sonucunu görelim.

Bu işlem için tekrar kayıt ekliyor;


Resim-19

Gerekli inceleme sonrasında gördüğümüz LSN değerleri birbirlerini takip ediyor olacaktır.

Şimdide log yedeği sonrasında işlenmiş log kayıtlarının silindiğini ve Veritabanı log kullanımlarının azaldığı görelim. İlk olarak log dosyalarının büyümesine neden olan komutlar çalıştıralım ve sonrasında Veritabanı log kullanım oranlarını görelim.


Resim-20

Log kullanım sonucu;


Resim-21

Şimdi Tekrar bir Log Backup alıyoruz.

1BACKUP LOG BACKUPTESTDB TO DISK=’D:\BACKUPTESTDB_LOG3.TRN’

Log Kullanım Durumu ;


Resim-22

Yedekleme Stratejilerini bu şekilde sizlere aktarmış bulunuyorum.

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

Referanslar

www.mshowto.org

 

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

Milenyumdan beri ilginç bir merak duygusu ile başlayan bilgisayar ve teknoloji dünyası merakı sayesinde eğitim yaşantımı doğup büyüdüğüm Düzce'de geçirdim. Sonrasında Düzce'nin kendimi geliştirmek adına yeterli imkanlara sahip olmadığından İstanbul'a gelip Bilge Adam Eğitim Kurumlarından Yazılım ve Veritabanı eğitimi aldım. Eğitimimi tamamlarken çeşitli Windows ve Web uygulamaları geliştirdim.Sırası ile Sentez Yazılım, Nebim Yazılım, Ciceksepeti, Doğan Holding, Kariyer.Net, TurkNet gibi firmalarında Yönetici / Müdür pozisyonlarında farklı ünvanlarda ( Yazılım Geliştirici / Raporlama ve Veritabanı Yöneticisi gibi) görev aldım. Şimdilerde ise DMC Bilgi Teknolojileri firmasının Kurucu Ortaklığını ve Veritabanı Danışmalığı Hizmeti vermekteyim.

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

Yorumlar (1)

    Bir yanıt yazın

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