Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 06.10.2011 15:27

 

Bu yazı, sql server için yedekleme ve kurtarma konusunda kendim için tuttuğum notlardan oluştuğu ve fazla düzenleme yapmadan burada paylaştığım için yazıdaki dilden dolayı özür dileyerek başlayayım.

Ayrıca okumadıysanız serinin ilk yazısına aşağıdaki linkten ulaşabilirsiniz.

Backup Restore Planlaması - I

Sql Server çok çeşitli backup süreçlerine sahiptir. Bunlar tek başlarına yada bir arada kullanılabilirler. Aynı zamanda backup sırasında database online ve kullanıcılara açık olabilir. Ayrıca sql server eş zamanlı olarak 64 backup device'ını destekler. MS Sql Server'da alternatif olarak şu backup çeşitleri bulunmaktadır :

Full Backup

- Transaction log dahil bütün verinin kopyası alınır.

- Restore edildiğinde backup alınan tarih/saate döner.

- Bütün backup stratejileri için alınması zorunlu olan backup çeşididir.

- En temel backup'dır ve bazen diğer backup'ların restore edilmesinden önce ilk olarak restore edilmesi gerekir.

- Full backup'dan restore yapıldığı zaman bütün database dosyaları (mdf, ldf, ndf's) restore edilir. Ardından database online olur ve transaction'lar açısından tutarlı konumdadır.

 

Partial Backup

- 2005 versiyonunda geldi.

- Veritabanının sadece değişen parçaları için backup alınmasının bir yoludur.

- Bu, backup alınma zamanını ve backup boyutunu düşürür.

- Primary filegroup ve read-write filegroup'ların bir kopyasıdır.

- Bu backup tipinin avantajlarından faydalanmak için değişmeyen referans dataları yada artık arşiv olmuş transactional dataları (partial table mantığı ile) bir filegroup'ta toplamak ve bu filegroup read-only olarak işaretlenmelidir.

- Partial backup sırasında primary filegroup'un ve read/write filegroup'ların backup'ı alınır. Optional olarak read-only filegroup'lar dahil edilebilir. Günde, haftada yada ayda bir kez de olsa, read-only filegroup'ların da backup'larını almak lazım.

- Özellikle read-only datası büyük olan bir db'de backup alınma süresini kısaltır

 

File/FileGroup Backup

- Veritabanındaki file yada filegroup'ların kopyasıdır.

- Çok büyük miktarda veriye sahip ve full backup alınması çok anlamlı olmayan db'ler için kullanılır.

- Eğer read/write files yada filegroups'ların backup'ı alınıyorsa, olası restore işlemi için log backup'da alınmalıdır.

- Bu backup çeşidinin dezavantajı şu olabilir : Büyük miktarda dataya sahip veritabanında çok sayıda file/filegroup olması olasıdır ve bunların bakımları, saklanması sorun teşkil edebilir. Aynı zamanda restore ederken bunların her birini restore etmek gereklidir ki bu da çok sayıda adım sonrasında restore işleminin tamamlanması anlamına gelir.

Not : Bir tablo ve o tabloya ait bütün indeksler aynı backup içerisinde yer almalıdır. Sql Server bunu kontrol eder ve bu kural ihlal edildiğinde hata verir. File/Filegroup backup kullanacaksak, index'lerin lokasyonu için backup plan'ını hesaba katmak gerekir.

 

Differential Backup

 - En son full backup'ın ardından değişen bütün dataların saklandığı kopyadır.

- Bir kayıta ait değişen datanın sadece son versiyonu saklanır. Değeri 5 olan bir veri full backuptan sonra sırasıyla 3,6,9 olarak update edilmişse differential backup içerisinde ilgili kayıtta sadece 9 verisi bulunur.

- En son full backup'a differential'ın base'i denir.

- Base ne kadar önceden alınmışsa, differential'ın boyutu o kadar büyüktür.

- Sql Server 2008 değişen extent'leri takip eder (bitmap page ile) ve bunların backup'ını alır.

Not : Sql server veriyi page'lerde tutar. Page 8k'lık veri saklayan en küçük veri saklama birimidir. Yani 1mb'da 128 page bulunur.

Bununla birlikte extent, 8 tane page'in bir araya gelmesiyle meydana gelen veri saklama birimidir. Yani 1 mb'da 16 extent bulunur.

Yukarıdaki şemada 24 tane extent var. Differential backup alındığı sırada bunların 6'sındaki data değişmiş. Değişmeyen extent'ler 0, değişen extentler 1 ile işaretlenerek bir differential bitmap page oluşturulur. Differential backup sırasında bu bitmap page'e göre hangi extent'lerin backup'ının alınacağına karar verilir.

- Differential backup'lar kümülatiftir.Pazar gecesi full backup aldıktan sonra Pazartesi akşam differential backup alırsak, bu Pazar gecesinden itibaren gerçekleşen bütün değişiklikleri içerir. Salı akşam bir differential backup daha alırsak, bu 2.differential backup yine Pazar gecesinden itibaren meyadana gelen bütün değişiklikleri içerecektir. Restore etme ihtiyacı olduğunda önce en son full backup restore edilir, ardından o full backup'dan sonra alınan en son differential backup restore edilmelidir. Ardından da son differential backup'dan sonra alınmış eldeki transaction log backup’lar restore edilir. Bu şekilde hızlı bir biçimde kurtarma operasyonu tamamlanır.

 - Full database backup'dan sonra ne kadar miktarda datanın değiştiğine göre differential backup'dan faydalanma oranı değişir. Değişen kayıtlar, veritabanındaki kayıt miktarına yaklaşırsa o zaman yeni bir full backup alıp, ardından yeni bir differential ile devam etmek daha sağlıklı olacaktır.

 - Differential'ın bir diğer avantajı ise şöyle açıklanabilir. Bir grup veri, tekrarlayan bir job ile birlikte belirli aralıklarla değişiyorsa transaction log'un içerisinde bu değişikliklerin hepsi saklanır ve olası bir restore ihtiyacında bütün bu değişiklikler arka arkaya çalıştırılarak değişen verilerin en son değerleri elde edilir. Bu uzun süren bir restore süreci gerektirebilir. Eğer elde bu sürece ait differential backup'lar varsa, son diff. backup restore edilerek doğrudan verilerin son hali elde edilmiş olur.

  

Partial Differential Backup

 - Differential backup'la aynıdır. Sadece partial backup'daki datalarla eşleşir ve partial backup içerisindeki değişen verileri takip edip kayıt eder. Restore etmek için partial backup'a ihtiyaç vardır.

 - Sql Server Management Studio ve Maintenance Plan Wizard tarafından desteklenmez; sql script ile gerçekleştirilir.

  

File Differential Backup

- Alınmış en son file yada filegroup backup'dan sonra gerçekleşen değişikliklerin kopyasıdır.

- read/write files yada filegroups için alınan differential backup'dan sonra transaction-log backup alınması gerekir.

- Aynı şekilde file differential backup restore edildikten sonra transaction log backup'ın da restore edilmesi gerekir.

- File backup ve file differential backup, restore sürecinin kompleksliğini artırır.

 

Copy-only Backup

- Genellikle alınan backup'lar sonraki backup/restore serilerini etkiler, başlangıç-bitiş noktaları işaretler. Bunlar gerçekleşmeden mesela test yada uygulama geliştirme amaçlı backup, log backup almak için copy-only backup kullanılabilir.

- Dolayısıyla normal düzendeki sql backup/restore senaryolarının dışında backup çeşididir.

- Full backup ve transaction log backup için kullanılabilir.

- Full backup, differential backup'ları resetlerken copy-only full backup resetlemez.

- Transaction Log Backup, log'u truncate ederken, copy-only transaction log backup log'u truncate etmez ve aynı zamanda sonraki normal transaction log backup'ı etkilemez

 

Log Backup

3 çeşit olarak sayılabilir.

a) Pure Transaction-Log Backup

 - Bütün veri modifikasyonları, burada tutulur.

- En iyi veri koruma şeklidir.

- İstenen ana geri dönebilmeyi sağlar.

- Recovery model, Full yada Bulk-Logged olması durumunda alınabilir. Recovery mode Bulk-logged olarak set edildiyse, bulk işlemler log dosyasına yazılmaz. Simple recovery mode için alınması zaten anlamsızdır.

LSN=Log Sequence Number              SAN=Storage Area Network            WAL=Write Ahead Logging - this is a protocol

 b) Bulk Transaction-Log Backup

 - Recovery model, bulk-logged olduğunda alınan transaction-log backup çeşididir.

 - Syntax olarak pure transaction log backup ile farkı yoktur.

 - Sql server otomatik olarak db'nin o anki recovery model'ini detect eder.

 - Bu şekilde alınan bir log backup, zamanda istenen noktaya geri dönmeyi sağlamaz.

 - Bulk işlemlerin performansını artırmak için kısa süreliğine db'nin recovery modelini Bulk-Logged'a çekmek en doğru tercih olacaktır.

 - Transaction-log backup sırasında eğer bulk-loglanmış data varsa sql server bu datayı backup dosyasına dahil eder, bu yüzden log backup dosyasının boyutu küçük olmayacaktır.

 - Transaction log backup, restore edilmeden önce, eldeki en son full backup, ardından da varsa en son differential backup restore edilir. Bunların ardından full yada varsa differential backup'dan sonra alınmış transaction log backup'lar sırasıyla restore edilebilir.

 c) Tail Transaction-Log Backup

 - Veritabanı bozulduktan sonra alınabilecek transaction-log backup çeşididir.

 - Her gece full backup alınıyor, her saat başı transaction log backup alınıyor. Data dosyası saat 16.30'da bozuldu diyelim. Önceki geceye ait full backup ve ardından eldeki bütün transaction log backup'lar arka arkaya restore edildiğinde db'nin saat 16.00'daki durumuna geri dönülür. Ya 16.00 ile 16.30 arası? Data dosyası bozulmuş olsa da log dosyası hala sağlam. Bu durumda log dosyasından son bir transaction log-backup alınabilir. Bu da tail transaction log backup olur. Bu backup, son alınan transaction log backup'ın ardından gelen transaction'ları içerir. Tail backup'ın da restore edilmesinin ardından db, bozulduğu ana geri dönmüş olur.

 - Buradaki risklerden birisi, restore işlemlerine başlamadan önce tail log backup alınmasının unutulmasıdır. Aksiyon alınmadan önce tail log backup alınması gerekir.

 - Eğer db, bulk-logged recovery model'da ise ve bununla birlikte bulk işlemler gerçekleşmişse , tail transaction-log backup alınamaz. Çünkü bu durumda tail transaction-log backup, bulk işlemler sonucunda gerçekleşen data modifikasyonlarını data dosyasından elde etmek isteyecek; ancak data dosyamız bozuk olduğu için bunu gerçekleştiremeyecektir.

 - Management Studio üzerinden Tail log backup almak için Master db'ine yada başka bir database'e gidip bu işlemi yapmak lazım. Çünkü bizim database'imiz erişilmez durumdadır. Bunu yapmak için transaction-log back seçilir ve ardından aşağıda yer alan

            Backup the tail of the log and leave the database in restoring mode

 checkbox'ı seçilir. Bunun ardından database restoring mode'da bırakılır ve arkasından restore işlemleri sırayla yapılır, son olarak bu alınan tail log backup restore edilir.

 

 Attach/Detach

 Sql server'ı kapatıp, data dosyalarını kopyalamak ve sql server'a bağlanıp bunları ataçlamak.

 

 Backup Compression (Yedek Dosyasını Sıkıştırma)

 - Daha hızlı backup alma süreci ve daha küçük backup dosyası sağlar.

 - Bu işlem ram ve cpu harcar. O yüzden resource governor'dan ilgili administration işlemi için ram ve cpu sınırlaması yapılabilir.

 - Alınmış normal backup rar'landığında da %90'a kadar sıkıştırma yapılır.

 

Bu serinin sonraki yazısına aşağıdaki linkten ulaşabilirsiniz.

Backup Restore Planlaması - III

 

Kaynak : Wrox SQL Server 2008 Administration, MSDN

 

Yorum ekle

biuquote
  • Yorum
  • Canlı önizleme
Loading