Veritabanı Recovery Pending Durumu ve Düzeltme Seçenekleri

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?

1. 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.

2. 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.

3. 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

4. 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.

5. Veritabanı Restore İşlemi

Bir veritabanı yedeği (backup) geri yüklendiğinde (restore işlemi), işlem tamamlanana kadar veritabanı recovery durumunda kalabilir.

6. 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.

7. Veritabanı Dosyalarına Erişim Sorunu

Transaction log’un kazara silinmesi veya veritabanı dosyalarına erişimin kesilmesi durumunda recovery durumu yaşanır.

8. 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.

9. 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.

10. 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;

1. 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.

2. 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. 

3. Yetki Düzenleme

SQL Service kullanıcısının veritabanı filelarının bulunduğu dosyaya yazma yetkisi kontrol edilmelidir.  

4. 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. 

5. 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

6. 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.

 

7. 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/