Cihan Güngör | Bilişim Blog

MSSQL Recovery Mode Problemi

SQL Server – Veritabanı Yeniden Başlatıldıktan Sonra “Kurtarma” Modunda Kalmış

Bu, uzun süredir SQL Server ile çalışırken gözlemlediğim yaygın sorunlardan biridir.

SQL Server’ın yeniden başlatılması  veritabanı “Kurtarma” sürecinden geçecektir. Bu, veritabanının tutarlı bir durumda tekrar çevrimiçi olması gereken aşamadır. Süreçte üç alt aşama vardır. Keşif,  ileri ve Geri Alma. İsimler kendiliğinden açıklayıcı niteliktedir. Ayrıntılı olarak öğrenmek isteyenler için açıklayayım:

  • Analiz: SQL Server’ın LDF dosyasından geçeceği ve sonraki iki aşamada ne kadar işe ihtiyaç duyulduğunu anlamak için bellek içi yapıları oluşturma aşamasıdır.
  • İleri (redo): Veritabanının kapanması sırasında, taahhüt edilen ancak henüz kontrol noktası yoluyla MDF dosyasına yazılmamış işlemler olabilir.
  • Geri alma (geri alma): Kaydedilmemiş işlemler olsaydı, veritabanını tutarlı bir duruma getirmek için geri alınırlardı.

Veritabanını “InRecovery” durumunda gördüğümüzde?

  • SQL Server’ın yeniden başlatılması.
  • Veritabanı çevrimdışı ve çevrimiçi hale getirilmesi
  • Veritabanını yedekten geri yüklenmesi.

Yukarıdakilerin hepsine veritabanının “kurtarma” süreci denir ve tüm veritabanları daha önce açıklandığı gibi üç aşamadan geçmelidir.

Ne yapmalıyız?

Her zaman kontrol ettiğim ilk şey ERRORLOG . Errorlog’da, veritabanındaki ilk mesajı görmeliyiz (TestMe, veritabanının adıdır):

‘TestMe’ veritabanı başlatılıyor.

Bu, dosyalar açıldığı ve kurtarma işleminin başlatıldığı anlamına gelir. Bir ara sonra, 1. evreyi görmelisin.

‘TestMe’ (28) veritabanının kurtarılması% 0 tamamlandı (yaklaşık 37 saniye kaldı). 1. Faz 3. Bu yalnızca bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.
‘TestMe’ (28) veritabanının kurtarılması% 3 tamamlandı (yaklaşık 36 saniye kaldı). 1. Faz 3. Bu yalnızca bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.

Birinci aşama tamamlandıktan sonra, aşağıda gösterildiği gibi Aşama 2 ve 3 ile birlikte gider.

‘TestMe’ (28) veritabanının kurtarılması% 3 tamamlandı (yaklaşık 36 saniye kaldı). Aşama 2 / 3. Bu, yalnızca bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.
‘TestMe’ (28) veritabanının kurtarılması% 0 tamamlandı (yaklaşık 142 saniye kaldı). Aşama 2 / 3. Bu, yalnızca bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.
‘TestMe’ (28) veritabanının kurtarılması% 7 tamamlandı (yaklaşık 19 saniye kaldı). Aşama 2 / 3. Bu, yalnızca bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.
Ve tamamlandıktan sonra benzer bir şey kullanmalısınız.

‘TestMe’ veritabanında 3807 işlem ileri alındı ​​(28). Bu sadece bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.
0 işlemler ‘TestMe’ veritabanına geri döndü (28). Bu sadece bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmez.
Kurtarma ‘TestMe’ veritabanında bir denetim noktası yazıyor (28). Bu sadece bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmez. 30 saniye içinde
TestMe veritabanı (veritabanı kimliği 28) için kurtarma işlemi tamamlandı ( analiz 1289 ms, yeniden 29343 ms, tekrar 72 ms. ) Bu sadece bilgilendirme amaçlı bir mesajdır. Kullanıcı eylemi gerekmiyor

Yeşil renkte metin daha önce açıkladığım üç aşamayı açıklıyor.

Olası nedenler nelerdir?

  • İşlem günlüğü dosyasının büyük boyutu.
  • SQL, uzun süren bir işlem sırasında yeniden başlatılması.
  • Çok sayıda VLF.
  • SQL Server’da düzeltilen bir hataya neden olabilir. Aşağıda KB’yi referans aldım.

Bilinen sorunların listesi

SQL Server 2005, 2008, 2008 R2 veya SQL 2012 kullanıyorsanız, lütfen aşağıda verilen düzeltmeleri uyguladığınızdan emin olun.

http://support.microsoft.com/kb/2455009 (DÜZELTME: SQL Server 2005, SQL Server 2008 veya SQL Server 2008 R2’de işlem günlüğüne çok sayıda VLF varsa bir veritabanı kurtarırken yavaş performans)

http://support.microsoft.com/kb/2524743 (DÜZELTME: Kurtarma, bir SQL Server 2008 veya bir SQL Server 2008 R2 ortamında bir veritabanı için beklenenden uzun sürüyor)

Düzeltmeler iyileşme evrelerini hızlandırmada yardımcı olacaktır. Bu blogun bazı SQL Server davranışlarına bakmak için bir yönde size yardımcı olmasını umuyoruz.

 

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

%d blogcu bunu beğendi: