SQL Server’daki bir Veri Tabanı ONLINE, SUSPECT, RESTORING, RECOVERING, RECOVERY PENDING, OFFLINE ve EMERGENCY durumlarından herhangi birinde bulunmaktadır.
Öncelikle Sql Server’daki Veri tabanlarımızı durumun nasıl kontrol etmeliyiz;
Bunun için şu Script’i çalıştırmamız bize Veri tabanlarımızın hangi durumda olduğunu gösterecektir.

 

Belirli bir veri tabanının mevcut durumunu kontrol etmek ise Scriptimiz.

Önemli Bilgiler Başlamadan Önce Mutlaka burayı okuyunuz.

REPAIR_FAST : Geriye dönük veri onarım işlevini gerçekleştirir. Veri kaybı olmaz fakat hata alma olasılığı diğerlerine göre daha fazladır.

REPAIR_REBUILD : Bir önceki işlevden bir sonuç alınamadığı zaman kullanılabilir, veri kaybı olmaz fakat hata alma olasılığı vardır.

REPAIR_ALLOW_DATA_LOSS : Rebuild yaptığınız halde hata almışsanız bu işlemi deneyebilirsiniz fakat veri kaybı olasılığı vardır. Bu nedenle öncesinde yedekleme yapılmalıdır.

Önemli bir hatırlatma : Suspect modundaki veritabanını sakın “Detach” etmeyin yoksa bir daha “Attach” edemezsiniz. Bu yüzden mutlaka ilk iş olarak .mdf ve .log dosyalarını yedekleyiniz. Her denemeden sonra SQL server’ ı yeniden başlatmayı unutmayın.

SQL Server Veritabanı Durumu Türleri

Yukardada belirttiğimiz gibi bu durumları inceliyeceğiz.

1.ONLINE

Temel olarak, ONLINE durumdaki bir SQL veritabanı sağlıklıdır ve normal şekilde çalışır. İdeal olarak, bir veritabanı SQL Server’da başlatıldığında bu duruma geçmelidir.

2.OFFLİNE

SQL Veri Tabanı, kullanıcı erişimi için kullanılamaz durumda kalır. Bir veri tabanı, açık kullanıcı eylemiyle Çevrimdışı olarak ayarlanır.

Neden OFFLINE Çekeriz?

Database dosyalarını yeni bir sürücüye taşımanız veya kullanıcıların database’e erişmesini engellemeniz gerektiğinde yardımcı olur.

3.RESTORING

SQL server da veri tabanı çeşitli sebeplerden dolayı “restoring state” e geçebilir.

Bu durumlar; yedekten geri dönmek istediğimizde “back up the tail log, and leave database in the restoring state” seçeneği ile log yedeği almış olabiliriz, farklı sunucular arasında veri aktarması yaparken hedef sunucudaki veri tabanı restoring state durumunda kalmış olabilir ya da mirroring gibi uygulamalarda veri tabanımız gene bu konumda kalmış olabilir.

Restoring state duruma geçen veri tabanı yukarda örneğini vermiş olduğum durumlar tamamlana kadar konumunu korur. Örneğin yedekten dönme işlemi tamamlanınca eski haline gelir.

Bazı durumlarda veri tabanı restoring state konumundan çıkamaz.

Bu tür durumlarda aşağıdaki sorguyu çalıştırmamız veri tabanının eski haline gelmesini sağlayabilir.

Veri tabanımız eski haline gelecektir.

Geri yükleme(Restore) seçeneklerinde ”NORECOVERY” geri yükleme seçeneği kullanılarak birden fazla yedekleme dosyası geri yüklenirken, WITH RECOVERY seçeneği kullanılarak son yedekleme dosyasına ulaşılmadığı sürece Database, RESTORING modunda kalır.

    Database =>Restore Database =>Optıon   Adımlarını izleyerek Recovery State Alanınızı Seçebilirsiniz

Unutmayalım.

“AlwaysOn ‘a yeni Eklenecek bir database için AlwaysOn makinalarında RESTORING modda açılıp Availability Groups içine alınır.

4.RECOVERING

SQL Server yeniden başlatıldığında veya veritabanı sunucuya eklendiğinde geçici olarak RECOVERING olarak değişir. Databases “In Recovery” modunda olan databases kurtarılıyor durumundadır. Bu durumda iken Datanbase kullanılamaz.

Database kurtarma işleminde takılı kalmış gibi görünsede aslında 3 aşamadan geçmektedir.ve bu aşamaların tamamlaması gerekmektedir.

Bu aşamalar ise Analysis(Analiz), Redo(Yeniden Yap), ve Undo(Geri Al) dır. Bu durumlara daha detaylı Buradaki makalemden ulaşabilirsiniz..

Bazen Databese “In Recovery” modunda kalabilir yani Recovery modunda böyle bir durum Large Transaction Log dosyası, SQL Server’daki bir hata nedeniyle ortaya çıkabilir. Bu yüzden “In Recovery” aşamasını sabırla beklemeniz gerekmektedir.

In Recovery” işlemi tamamlandıktan sonra Database ONLINE olur. Bu işlem başarısız olursa PENDING  veya Recovery PENDING durumuna geçer.

5.RECOVERY PENDING

Veritabanınız RECOVERY PENDING (Kurtarılmayı Bekliyor) durumunda kalmışsa bu, kurtarma işleminin başarısız olduğu anlamına gelir . İyi haber şu ki, muhtemelen veritabanı zarar görmemiş. Ancak, kullanıcı erişimi için kullanılamayacak ve hatayı düzeltmek ve kurtarma işleminin başarıyla tamamlanmasını sağlamak için daha fazla kullanıcı eylemi gerektirecektir

Ne yapmalıyız.

İlk önceliğimiz her zaman elimizde bir backup bulundurmak olacaktır.

Manuel Olarak 2 Yol Bulunmakta

1.Veritabanını Emergency Modunda İşaretleyin ve Zorunlu Onarımı Başlatın

2. Veritabanını Emergency Modunda İşaretleyin, Ana Veritabanını Ayırın ve Yeniden Ekleyin

6.SUSPECT

Bir DBA’nun istemeyeceği durumlardan biridir.

SQL veritabanının şüpheli modda olmasına neden olabilecek çok çeşitli hatalar vardır . Bunlardan bazıları aşağıda listelenmiştir:

• Sistem, SQL sunucusunun verilerinin veya günlük dosyasının bulunduğu aygıtı açamıyor.
• Bir işlemin ortasında SQL sunucusu çöküyor veya yeniden başlatılıyor, bu da işlem günlük dosyasının bozuk veya erişilemez olmasına neden oluyor.
• SQL Server bir veritabanını açmaya çalışır ve o veritabanına ait dosya zaten sisteminizde kurulu olan antivirüs yazılımı tarafından açıktır.
• Veritabanı anormal bir şekilde sonlandırıldı.
• Disk alanı eksikliği.
• SQL bir geri alma veya ileri alma işlemini tamamlayamıyor.
• Veritabanı dosyaları işletim sistemi, üçüncü taraf yedekleme yazılımı vb. tarafından tutulmaktadır.

Database(Suspect) hatası bu hatadan nasıl kurtulabileceğinizi kısa ve basitçe anlatmak istedim.

Not : Suspect modundaki veritabanını sakın “Detach” etmeyin yoksa bir daha “Attach” edemezsiniz. Bu yüzden mutlaka ilk iş olarak .mdf ve .log dosyalarını yedekleyip aşağıdaki yöntemlerle şansınızı deneyin. Her denemeden sonra SQL server’ ı yeniden başlatmayı unutmayın.

Aşağıdaki Komutları Uygulayınız :

 

Not : Yukarıdaki işlemde veri kaybı göz alınmıştır. Veri kaybı toleransınız yok ise ” REPAIR_ALLOW_DATA_LOSS ” komutunu REPAIR_FAST veya REPAIR_REBUILD olarak deneyiniz. Son çare olarak REPAIR_ALLOW_DATA_LOSS demenizi tavsiye ediyorum.

7.EMERGENCY

Bir veri tabanı, sorun giderme amacıyla EMERGENCY durumuna ayarlanabilir. Veri tabanı, tek kullanıcı modunda olacaktır ve onarılabilir veya geri yüklenebilir. Yalnızca sysadmin ayrıcalıklarına sahip bir kullanıcı veritabanı durumunu EMERGENCY olarak değiştirebilir.

EMERGENCY modu, SQL kullanıcılarının SUSPECT olarak işaretlenmiş veya Recovery PENDING‘ durumunda kalmış bir veri tabanına girmelerini sağlayan bir durumdur.

Veri tabanını onarmak veya geri yüklemek için tek kullanıcı moduna geçirir. EMERGENCY durumu, veri tabanına yalnızca “sysadmin sabit sunucu rolü üyelerine” READ_ONLY (ve kısıtlı) erişimi sağlar.

Veritabanı durumunu acil durumdan normale (yani çevrimiçi) değiştirmek için aşağıda verilen adım adım talimatları izleyin:

Adım 1: Database’i acil durum moduna ayarlamak için aşağıdaki T-SQL komutunu kullanın:

Not: Bazen, birkaç aktif bağlantı nedeniyle db durumunu ACİL moduna değiştiremeyebilirsiniz. “sp_who2” komutunu kullanarak SQL Server’daki aktif bağlantıları tespit edebilirsiniz. Yani Database’i kullanan aktif kullanıcıları gösterir.

Algılandıktan sonra, aktif Sessionların tamamlanmasına izin verin veya “KILL” komutunu kullanarak oturumları manuel olarak sonlandırın:

Adım 2: Aşağıdaki komutu kullanarak veritabanını normal (ÇEVRİMİÇİ) durumuna geri yükleyin:

Adım 3: SQL Veritabanı Bozuksa Ne Olur?

Hasarlı (bozuk) bir veritabanını ACİL durumdan ÇEVRİMİÇİ duruma geri yüklemeye çalışmak, veritabanını SUPPECT moda döndürür. SQL veritabanı bozuksa, onu bilinen son iyi yedekten geri yüklemeyi deneyin.

Ancak, yedekleme güncellenmediyse veya hasar gördüyse, db’yi onarmak için veri tabanında REPAIR_ALLOW_DATA_LOSS seçeneğiyle DBCC CHECKDB’yi çalıştırın:

Not: Veri kaybına yol açabileceğinden son çare olarak DBCC CHECKDB’yi ‘REPAIR_ALLOW_DATA_LOSS’ ile kullanın.

Database State tiplerinden bahsetmeye çalıştım umarım yararlı olmuştur.