“Database ‘x’ cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details” ve “Initializing / Recovery Pending” Hatasının Çözümü
Bu hatanın birkaç sebebi olabilir. Bir arkadaşım bu hatayı aldığında veritabanı dosyalarının silindiğini söylemişti. Backup’tan dönerek sorunu çözmüşlerdi.
Always ON’da Secondary veritabanı bazı durumlarda(kontrolsüz server restart’ı vb.) Initializing/Recovery Pending mode’una düşüyor. Ben Always ON kullanırken secondary veritabanım Initializing /Recovery Pending mode’una düştüğünde veritabanını AG üzerinden suspend ve sonrasında resume yapmak istediğimde bu hatayı aldım. Suspend mode’a aşağıdaki iki yöntemle alabilirsiniz. Bazen secondary veritabanı fail olursa suspend ve sonrasında resume yapmak sorunu çözüyor. Bu sorunda çözmedi tabi.
Script kullanarak;
SSMS üzerinden Availability Databases sekmesinden ilgili veritabanına sağ tıklayarak Suspend Data Movement diyerek;
Bunun üzerine secondary veritabanında Availability Databases sekmesinde Remove Secondary Database…’e tıklıyorum.
Bu işlem sizi biraz bekletebilir. Çünkü veritabanının Initializing / Recovery Pending’e düşmesinin sebebi secondary veritabanının yapısındanki bir problem nedeniyle oluşmuştur. Ve bunu recover etmek için bir süreye ihtiyaç duyar.
SQL Server Log’una baktığımda aşağıdaki gibi işlemin sürecini takip edebilirim. Veritabanının büyüklüğüne göre bu süre değişecektir. 6 TB’lık bir veritabanı için ben 7 saat bekledim. Secondary veritabanı olduğu için kesinti yaşanmadı.
Recover işlemi tamamlandıktan sonra Secondary sunucuda Availability Databases kısmında sorunlu veritabanımızın üstünde ! İşareti olduğunu göreceksiniz. Bu veritabanı üzerinde sağ tıklayıp Join to Availability Group… diyoruz. Bir süre sonra secondary veritabanının status’ünün tekrar synchronized olduğunu ve sorunun düzeldiğini göreceksiniz.
Eğer bu sorun olduktan sonra primary veritabanından log backup aldıysanız aşağıdaki gibi bir hata ile karşılaşabilirsiniz. Primary veritabanından aldığınız log backup’ı secondary sunucuya tekrar restore edip aynı işlemi tekrar denemeniz gerekir. Eğer log backup’ı bulamıyorsanız ya da başka bir backup uygulaması ile aldıysanız önce bir differential backup ardından log backup alıp restore etmeyi deneyebilirsiniz. Eğer differential backup almak çok uzun sürüyorsa secondary sunucuda restoring mode’da olan veritabanını silip primary’deki veritabanını ag den çıkarıp tekrar ag’ye almak kesin çözüm olacaktır.
The mirror database,””, has insufficient transaction log data to preserver the log backup chain of the principal database. This may happen if a log backup principal database has not been taken or has not been restored on the mirror database.