Veritabanının neden RESTORING durumunda takılı kalmasının temel nedenini belirleyin

Durumda sıkışmış bir veritabanı sorununu çözen ve RESTORINGmanuel olarak veritabanını tekrar çevrimiçi hale getirmek için bu çözümleri kullanan sorular olduğunu biliyorum , ancak benim senaryo biraz farklı.

Üretim kopyasını DEV örneğine geri yükleyen Powershell komut dosyalarını kullanarak otomatik bir geri yükleme var. Komut dosyaları yaklaşık bir yıl boyunca değişmez ve bazen geri yükleme işlemi sona erer, ancak geri yüklenen veritabanı durumda kalır RESTORING(bazen komut dosyası iyi çalışır, bazen bu şekilde başarısız olur).

İşlemi manuel olarak yeniden çalıştırırsam veya veritabanını SSMS'nin kullanıcı arabiriminden veya T-SQL'den manuel olarak geri yüklersem her sorun olmadan tamamlanır.

Geri CHECKDByüklenen DB çalıştırmak için önerilen cevaplar buldum ama hiçbir şey bu sorunun nedeni olarak çıktı.

Geri yükleme komut dosyaları veritabanının TAM bir yedeğini geri yüklediğinden ve bir "WITH RECOVERY"seçenek kullandığından , geri yükleme işlemini neyin durdurabileceğini bulmaya çalışıyorum, ancak aslında geri yüklüyorum "WITH RECOVERY".

Bunun zaman zaman neden olduğunu anlamaya çalıştığım için herhangi bir öneri gerçekten takdir ediliyor.

Ben bir kez daha DB manuel olarak geri yüklemek için belirtileri tedavi yerine, sorunun kök nedenini çözmek istiyorum.

Güncelleme:

@Brent olarak Github Gist önerilir - burada .

— Radu Gheorghiu
kaynak

Cevabı SQL Server günlüklerinden ve olay görüntüleyiciden alabilirsiniz, kontrol ettiniz mi? Bir şekilde alan sorunu var mı, çünkü bu geri yükleme durumunun sıkışmasına neden olabilir. Geri yüklemeden önce yedekleme bütünlüğünü doğrulıyor musunuz? Depolama altsisteminiz nasıl

— Shanky

@Shanky Bu bilgilere doğrudan erişimim olmamasına rağmen, bunlara bir göz atacağım (SAN yöneticimle tanışmam gerekiyor). Yedekleme bütünlüğü, hem yedekleme sırasında hem de diske yazılırken kontrol edilecek şekilde ayarlanmıştır.

— Radu Gheorghiu

SQL Server hata günlüğü ne diyor? Çalışmayı deneyin EXEC sys.xp_readerrorlog 0,1;- geri yükleme işlemi sırasında iletileri arayın.

— Max Vernon

@ MaxVernon Geri yüklemenin gerçekleştiği andaki hata günlüğü . Hata mesajını kontrol ettim ve bol olan disk alanını kontrol etmeyi tavsiye ediyor gibi görünüyor. Daha derine ineceğim ve ne bulabileceğimi göreceğim, ancak hızlı bir bakışta bu oldukça genişleyebilir ve birçok şeye bakmamı sağlayabilirdi .

— Radu Gheorghiu

Occam'ın tıraş bıçağı açıktan başlamayı önermektedir:

Betiğiniz bazen bir veritabanını geri yükleme durumunda bırakırsa, betiğin hatalarını ayıklayın.

Bir tablo veya dosyada ne yaptığınızı günlüğe kaydederek başlayın. Ardından, veritabanını geri yükleme durumunda bulduğunuzda, neyin yanlış gittiğini görmek için günlüklerinize geri dönün. (Topluluktan ikinci bir göz kümesi istiyorsanız, komut dosyanızı Github Gist olarak yüklemeyi deneyin, ancak ne kadar büyük olursa, hataların farkına varmanın o kadar zor olabileceğini unutmayın.)

Bunu yapmak istemiyorsanız, geri yükleme olaylarını izlemek için bir Profiler veya Genişletilmiş Etkinlikler izi çalıştırmayı deneyin, ancak uyarı alın - göründüğünden çok daha zor. (Denedikleri ve başarısız oldukları daha fazla okuyucu fikri için bu yayındaki yorumları okuyun.)

— Brent Ozar
kaynak

Teşekkürler Brent, bunlar bazı iyi yönergeler! Daha fazla bilgi aldığımda bir güncelleme ile döneceğim, DB'nin iyi olduğu an için, süreç yarın sabah tekrar çalıştığında ne olacağını göreceğim.

— Radu Gheorghiu