SQL Server Felaketten Kurtarma – MDF Dosyasına Erişilemiyor!

Her şey yolunda, yönetmiş olduğunuz veri tabanlarınız sorunsuz çalışıyor. Öğle yemeğindesiniz veya kahve molasına çıktınız. Bir telefon geliyor, arayan yöneticiniz. Tüm sistemlerin durduğunu verilere erişemediklerini iletiyorlar. Apar topar soruna müdahale etmek için veri tabanı sunucularına bağlandınız. Çok yoğun kullanmış olduğunuz bir veri tabanı artık erişilebilir değil. Sorunu tespit etmek için hata kayıtlarına bakıyor, diskleri kontrol ediyorsunuz. Sorunu tespit ettiniz, data (Veri) dosyalarının tutulduğu disk görünmüyor. Herhangi bir sebepten dolayı data (Veri) dosyanız (.mdf) artık erişilebilir değil.

Sorun tespit edildiğine göre çözüm için çalışmaya başlayabilirsiniz. Yedeklerinizi günlük alıyorsunuz ve son alınan yedek üzerinden 12 saat geçmiş. Yöneticiniz size bir saniyelik verinin bile ne kadar önemli olduğunu 12 saatlik veri kaybının kabul edilemez olduğunu hatırlatıyor J Artık işinin ehli bir veri tabanı yöneticisi olarak veri tabanlarını tekrar kullanıma almak için çalışmaya başlıyorsunuz.

Not: İşinin ehli olan bir veri tabanı yöneticisi yönetimi altında olan veri tabanları için doğru yedekleme stratejisini uygular. SQL Server Yedekleme Stratejileri Nelerdir?

Yukarıda anlatmış olduğum senaryo ile karşılaştığımızda ne yapmalı, veri tabanını kayıpsız bir şekilde nasıl tekrar kullanama alacağımıza bakalım. Senaryomuzda kullanmak için bir veri tabanı oluşturuyorum.

Resim-1

Veri tabanımızı oluşturduktan sonra “DemoTable” adında bir tablo oluşturuyoruz.

Resim-2

Üç kolonlu yeni bir tablo oluşturup içerisine bir tane kayıt ekliyorum. Tablo içeriğim aşağıdaki gibidir;

Resim-3

Buraya kadar yeni bir veri tabanı ve bu veri tabanı içerisine bir tane tablo oluşturup bir tane de kayıt eklemiş olduk. Şimdi veri tabanımızın tam yedeğini alacağız eğer veri tabanımızın Recovery Model (Kurtarma Modeli) Full (Tam) değilse aşağıdaki sorguyla Recovery Model değerini değiştirebilirsiniz.

Resim-4

Artık Full Backup (Tam Yedek) almak için hazırız. Aşağıdaki sorgu ile veri tabanımızın yedeğini alıyoruz.

Resim-5

Veri tabanımızı başarıyla yedekledik. Veri tabanımızda oluşturduğumuz tabloya bir tane kayıt ekleyip yedekleme işlemini yapmış olduk. Şimdi veri tabanımıza yeni kayıtlar ekleyelim.

Resim-6

Başarıyla almış olduğumuz son yedekten sonra tablomuza 3 tane daha kayıt ekledim. Şimdi herhangi bir sebepten dolayı data (Veri) dosyamızın erişilemez olduğu durumda nasıl felaketten kurtulabiliriz, bunun senaryosunu hazırlayalım. Ben bu senaryo için SQL Server Database Engine servisini durdurduktan sonra MsHowToDB veri tabanıma ait olan “MsHowToDB_data.mdf” veri dosyasını siliyor olacağım. Öncelikle veri dosyamı silmek için SQL Server Database Engine servisini aşağıdaki komutla durduruyorum.

Resim-7

SQL Server Database Engine servisini durdurduktan sonra data (Veri) dosyamın bulunduğu dizine gidip ilgili dosyayı siliyorum.

Resim-8

Veri tabanı data (Veri) dosyasını sildikten sonra SQL Server Database Engine servisini başlatıyorum.

Resim-9

Servisi başlattıktan sonra SQL Server Management Studio ile Instance ‘ımıza bağlanıyoruz. Bağlantı kurduktan sonra Object Explorer penceresinde veri tabanımızın Recovery Pending olarak kaldığını ve artık erişilemez olduğunu görüyoruz.

Resim-10

Bu adıma kadar tüm hazırlığımızı gerçekleştirmiş olduk. Her veri tabanı yöneticisinin başına gelebilecek bir durumu test etmiş olduk. Şuan elimizde veri tabanımızın tam yedeği mevcut ve bu yedekten sonra veri tabanımıza yeni kayıtlar eklendi. Bu durumda data (Veri) dosyası erişilebilir olana kadar veri tabanı Recovery Pending durumunda kalmaya devam edecektir.

Data (Veri) dosyamız erişilemez olmasına rağmen Log (Günlük) dosyamız erişilebilir durumda. Tam yedek sonrası oluşan değişiklikleri almak için Log Backup (Günlük Yedeği) almamız gerekiyor.

Resim-11

Log (Günlük) yedeği almaya çalıştığımızda yukarıdaki resimdeki gibi bir hata ile karşı karşıya kalıyoruz. Veri tabanımız erişilemez olduğu için Log (Günlük) yedeği alırken özel bir keyword (Anahtar Kelime) kullanmamız gerekiyor. Şimdi Log (Günlük) yedekleme sorgumuzu aşağıdaki gibi düzenliyoruz.

Resim-12

Bilindiği gibi alınan Log Backup (Günlük Yedeği) sonrasında Log (Günlük) dosyasının içeriği temizlenir. Veri tabanımız erişilemez olduğu için SQL Server veri bütünlüğünü sağlamak için NO_TRUNCATE komutu kullanmadan Log (Günlük) yedeği alınmasına izin vermemektedir.

Log (Günlük) dosyamızın yedeğini aldıktan sonra veri tabanımızı çalışan son haline getirmek için yedeklerimizi geri yüklemeye başlayalım. Önce alınan Full (Tam) yedeğimizi Restore (Geri Yükleme) ediyoruz.

Resim-13

Alınan Full (Tam) yedeği “NORECOVERY” komutu ile geri yüklüyoruz. Bu komut ile beraber yedek yüklediğimizde işlemin tamamlanmadığını, başka bir yedek dosyasının daha veri tabanı üzerine dönüleceğini bildiriyoruz. Bu aşamada veri tabanımız “Recovery Pending” durumundan “Restoring” durumuna dönüyor. Artık veri tabanımız erişilemez durumundayken almış olduğumuz yedeğimizi yükleyelim.

Resim-14

Log (Günlük) yedeğimizi de geri yükledikten sonra yukarıdaki resimde görüldüğü üzere artık veri tabanımız kullanılabilir duruma gelmiş oldu. Geri yükleme sorgusunda bu sefer “RECOVERY” komutunu kullanarak yedeği yükledim. Bu komut ile SQL Server’ a başka bir yedek dosyası daha yüklemeyeceğimi bu dosyadan sonra veri tabanını kullanıma almasını bildiriyorum.

Yedeklerimizi başarıyla yükledik veri tabanımız şuan aktif duruma geldi. Peki, alınan tam yedekten sonra yapılan kayıtlar duruyor mu? Hemen tablomuzu sorgulayalım.

Resim-15

Görüldüğü gibi hiçbir veri kaybı olmadan kayıtlarımızı kurtarmış olduk. Şimdi yöneticimizden zam talebinde bulunabiliriz J

Bu makalemizde olası bir veri kaybı durumundan nasıl kurtulabileceğimizi test etmiş olduk. İyi bir veri tabanı yöneticisi bu durumla karşı karşıya kalmamak için doğru bir yedekleme stratejisi belirlemeli, SQL Server’ in sunmuş olduğu High Availability (Yüksek Erişe bilirlik) ve Disaster Recovery (Felaketten Kurtulma) çözümlerini kullanmalıdır.

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

Referanslar

www.mshowto.org

TAGs: SQL Server, Disaster Recovery, SQL Server Data Recovery, SQL Server Veri Kurtarma, Full Backup, Log Backup, High Availability, Recovery mdf file, restore log, restore backup, backup log with no_truncate