SQL Server Database States

SQL Server Database States

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ınDetach” 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ü üyelerineREAD_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.

 

 

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 gün önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 3 hafta önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL 3 hafta önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele