Veritabanı Recovery Pending Durumu Nedir?
SQL Server’da veritabanları bazı nedenlere bağlı olarak “Recovery Pending” (Kurtarma Bekleme) moduna geçebilir. Veritabanın düzgün bir şekilde kapatılmaması, eksik veya bozuk log dosyaları, disk depolama sorunları, sistemde yaşanan anormal şekilde çökmeler veya MS SQL Server’daki hatalar bu duruma sebep olabilir. Recovery durumu, aslında veritabanını tekrar kullanılabilir hale getirmek için bir kurtarma işlemi yürüttüğünü ifade eder ve üç aşamadan oluşur;
Analysis (Analiz): Transaction log incelemesi yapılması ve işlemlerin tamamlanma (Commit) durumunun kontrol edilmesi,
Redo (Yeniden İşleme): Tamamlanmış (Commit) ancak henüz diske yazılamamış olan işlemlerin yeniden işlenmesi,
Undo (Geri Alma): Başlamış (Begin) ancak tamamlanmamış (Commit) işlemlerin geri alınmasıdır.
Veritabanı Neden Recover Pending Duruma Düşer?
- SQL Server Restart Süreci
SQL Server servisi restart edildiğinde üzerinde bulunan tüm veritabanları tutarlılığın sağlanması için otomatik olarak recovery moduna girer ve redo/undo işlemleri sürecince devam eder.
- Ani Sistem Kapanışları
Elektrik kesintisi, donanım arızası vb. gibi nedenlerle SQL Server beklenmedik şekilde aniden kapanması durumunda, işlemler yarıda kalabilir. Bu durumda kalan işlemlerin düzeltilmesi esnasında Recovery durumda kalabilir.
- Transaction Log Sorunu
Log dosyalarının dolması veya bozulması durumunda işlemlerin başarılı bir şekilde tamamlanıp tamamlanmadığının belirlenmesi esnasında yaşanabilir
- Veritabanı Bozulması
SQL Serverin kurulu olduğu ortamda yaşan donanım sorunları, disk hataları veya yanlış yapılandırma gibi nedenlerle veritabanı dosyaları (MDF veya LDF) bozulabilir. Buna bağlı olarak veritabanı recovery durumda kalabilir.
- Veritabanı Restore İşlemi
Bir veritabanı yedeği (backup) geri yüklendiğinde (restore işlemi), işlem tamamlanana kadar veritabanı recovery durumunda kalabilir.
- Hatalı Veritabanı Durumu
İşlem sırasında anormal bir durumun oluşmasına veya tutarsız bir durumun ortaya çıkması recovery moduna girmesine neden olabilir.
- Veritabanı Dosyalarına Erişim Sorunu
Transaction log’un kazara silinmesi veya veritabanı dosyalarına erişimin kesilmesi durumunda recovery durumu yaşanır.
- Disk Doluluk Durumu
Veritabanına ait MDF veya LDF dosyalarının bulunduğu disklerde yeterli boş alan kalmaması ve dosyaların büyüyememesi durumunda recovery duruma geçebilir.
- Folder Yetki Eksikliği
SQL Service kullanıcısının veritabanı dosyalarının bulunduğu dosya dizinine yazma yetkisi bulunmadığı durumlarda da yaşanabilir.
- Auto Close Options
Auto Close özelliği; Veritabanı üzerindeki son kullanıcı bağlantısını kapattığında, veritabanının kapatılarak sunucu üzerindeki (veritabanının kullandığı) kaynakların kullanılabilir olmasını sağlamaktadır. Veritabanı kapatıldığında, bir sonraki kullanıcının erişimi daha uzun sürer.
Recovery Pending Durumu Nasıl Çözülür?
Recovery durumu, genellikle veritabanı tutarlılığını sağlamak için gerekli bir işlemdir. Ancak sürekli recovery durumunda kalan bir veritabanı, bir altyapı sorunu olduğunu gösterebilir. Bu duruma bağlı olarak öncelikle temel kontroller yapılmalıdır. Sorunun düzelmediği durumlarda müdahale edilir.
Temel kontrol ve müdahale seçenekleri aşağıdaki şekildedir;
- Sürecin Tamamlaması
Recovery işlemi genellikle SQL Server tarafından otomatik olarak tamamlanır. Recovery durumu uzun sürmesi log dosyasının büyümesi veya disk performansına bağlı olarak değişikli gösterir.
- Disk Doluluk Durumu
Disk dolmasından kaynaklı durum yaşandığında; disk üzerinden boş alan açıldıktan sonra SQL Servis restartı ile durum toparlanır.
- Yetki Düzenleme
SQL Service kullanıcısının veritabanı filelarının bulunduğu dosyaya yazma yetkisi kontrol edilmelidir.
- Transaction Log’u Temizliği
Transaction log dosyası dolmuş ve recovery durumu devam ediyorsa, log dosyasını küçültmek veya yeniden boyutlandırmak gerekebilir:
DBCC SHRINKFILE (LogFileName, Size); BACKUP LOG [DatabaseName] WITH TRUNCATE_ONLY;
Uyarı: TRUNCATE_ONLY işlemi, transaction log içeriğini kaybedebileceğinden buna göre işelem yapılmalıdır. kullanılmalıdır.
- Auto Close Özelliği Düzenleme
Bu özelliğin açık olduğu databaseler de benzer durum yaşanabileceğinden bu özellik kontrol edilmelidir. Best practicede kapalı kalması uygundur.
- Management Studio (SSMS) ile
Database > (Sağ Tık) Properties > Options > Automatic > Auto Close False
- T-SQL ile
--Ayarı aktif etmek için ALTER DATABASE [DatabaseName] SET AUTO_CLOSE ON WITH NO_WAIT GO --Ayarı pasif etmek için ALTER DATABASE [DatabaseName] SET AUTO_CLOSE OFF WITH NO_WAIT GO
- Veritabanı Onarımı:
Log file’a erişimin sağlanmadığı durumlar veritabanını normale döndürebilmek için yeni bir log file oluşturularak veritabanı ayağa kaldırılabilir. Bu duruma daha önce log da kalmış işlem kayıtlarını kaybetmeyi göze almış olarak devam edilebilir. Dikkat edilmelidir.
1.Yöntem
Veritabanı loglarını göz ardı ederek bozulma kontrolü yaparak düzeltme
-- Acil durum moduna alınır. Bu mod veritabanını yalnızca okuma/yazma ve sistem yöneticisi kullanıcıları için erişilebilir hale getirir. ALTER DATABASE [DatabaseName] SET EMERGENCY; GO -- Veritabanı üzerinde yapılacak işlemler sırasında yalnızca bir kullanıcının bağlanmasına izin verilir. ALTER DATABASE [DatabaseName] set single_user GO --Veritabanının kontrol edilerek bozuklukların onarılması sağlanır. Veri kaybı riski kabul edilir. Hata mesajlarını gösterir. DBCC CHECKDB ([DatabaseName], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS; GO ---- Veritabanı üzerinde yapılacak işlemler için çoklu kullanıcı bağlanmasına izin verilir. ALTER DATABASE [DatabaseName] set multi_user GO
İşlem sonrasında uyarı olarak; mevcut log dosyasına erişemediği için yeni bir log file oluşturulacağı ve veri tutarlılığı kaybedildiği ifade edilir.
2.Yöntem
Yeni bir log file oluşturarak kurtarma
-- Acil durum moduna alınır. Bu mod veritabanını yalnızca okuma/yazma ve sistem yöneticisi kullanıcıları için erişilebilir hale getirir. ALTER DATABASE [DatabaseName] SET EMERGENCY; --Log dosyası sorun olduğunda öncelikle veritabanı detach edilir. EXEC sp_detach_db [DatabaseName] --MDF dosyasının bulunduğu path belirtilerek tekrar attach edilir. Bu esnada SQL Server yeni bir log dosyası oluşturur. EXEC sp_attach_single_file_db @DBName = [DatabaseName], @physname =N'E:\MSSQL\DataFileName.mdf'
3.YÖNTEM
MDF dosyasının fiziksel pathini göstererek veri tabanını yeniden oluşturma
USE master; CREATE DATABASE [DatabaseName] ON (FILENAME = N'E:\MSSQL\DataFileName.mdf') FOR ATTACH_FORCE_REBUILD_LOG; --Or FOR ATTACH_REBUILD_LOG;
File path erişimlerinde yetki sorunu ile karşılaşabilirsiniz. SSMS’i yönetici modunda açarak işlem yapabilirsini.
Bu işlemde yer alan attach işleminde Force özelliğinin kullanımlarına da dikkat edilmelidir.
FOR ATTACH_REBUILD_LOG:
Log dosyası kaybolmuş, ancak veritabanı düzgün bir şekilde kapatılmış.
Tutarsızlık veya veri kaybı riski olmadan yeni bir log dosyası oluşturabilirsiniz.
FOR ATTACH_FORCE_REBUILD_LOG:
Veritabanı düzgün kapatılmamış veya bozulmuş.
Kurtarma için başka bir seçenek yoksa, bu yöntemi kullanabilirsiniz.
Önemli Not: Bu işlem sonrasında veritabanını kontrol etmek için mutlaka DBCC CHECKDB çalıştırılmalıdır.
- Yedekten Geri Yükleyin:
Eğer veritabanı onarılamayacak kadar bozulmuşsa, son alınan yedek dosyasını geri yüklenmelidir.
Sonuç
Recovery Pending duruma düşen veritabanı bir süre zarfı içerisinde normale dönmemiş işe data veya log dosyalarının bozulmasına bağlı olarak kayıtlarının kritikliği değerlendirilerek gerekli kurtarma yöntemleri uygulanmaktadır.
Kaynaklar
https://red9.com/blog/how-to-fix-recovery-pending-state-in-sql-server/
0 Yorum