SQL Server Veritabanı RECOVERY PENDING veya SUSPECT’te mi Kaldı? İlk Ne Yapmalı, Asla Ne Yapmamalı?

Uygulamanız bağlantı hatası vermeye başlıyor, biri SQL Server Management Studio’yu açıyor ve veritabanının yanında kimsenin görmek istemediği o ifade beliriyor: RECOVERY PENDING ya da SUSPECT. Bu noktadan sonraki on dakika, asıl arızadan daha belirleyicidir. Sahada, olayın kendisinden çok panikle yapılan müdahaleler yüzünden kaybedilen veriye defalarca tanık olduk: yanlış anda yapılan restart’lar, “yer açmak için” silinen dosyalar, hatta tamamen silinip yeniden kurulan sanal makineler.

Bu rehber, doğru sırayla ne yapmanız gerektiğini anlatıyor: durumu kesin olarak tespit edin, gerçek sebebi bulun, en az zarar veren çözümü seçin. Ve ne kadar acil hissettirirse hissettirsin, asla yapmamanız gerekenleri de.

Son doğrulama: 19 Ekim 2026. Microsoft Learn’deki veritabanı durumları, ALTER DATABASE, DBCC CHECKDB, KILL ve Accelerated Database Recovery sayfalarına karşı kontrol edildi. Microsoft’un veritabanı durumları sayfası SQL Server 2017 ve sonrasını ve Azure SQL’i kapsar; Accelerated Database Recovery SQL Server 2019 ile başlar. T-SQL örnekleri SQL Server 2025 (build 17.0.4055.5) üzerinde test edilmiştir.

Buradan Başlayın: İlk On Dakika İçin Teşhis Tablosu

Bir şeyi değiştirmeden önce sys.databases ve SQL Server error log’unda gördüğünüzü aşağıdaki satırlarla eşleştirin.

1. Adım: Veritabanının Durumunu Kesin Olarak Tespit Edin

Object Explorer’daki simgeye güvenmeyin; doğrudan SQL Server’a sorun. Aşağıdaki sorgu, veritabanının kendisi açılamıyorken bile çalışır:

SELECT name,
       state_desc,
       user_access_desc,
       is_read_only,
       recovery_model_desc,
       log_reuse_wait_desc
FROM sys.databases
WHERE state_desc <> 'ONLINE'
   OR name = N'VeritabaniAdi';

state_desc hangi durumda olduğunuzu söyler. log_reuse_wait_desc ise çoğu kişinin atladığı sütundur. Aşağıda göreceğiniz gibi, veritabanının bu duruma neden düştüğünü çoğu zaman bu sütun açıklar.

Hızlı Karar Tablosu: Her Durum Ne Anlama Geliyor?

Tablodaki tanımlar Microsoft’un veritabanı durumları dokümanına dayanıyor. Bu sayfaya gelenlerin çoğunu RECOVERY PENDING ve SUSPECT getiriyor; şimdi ikisini sırayla ele alalım.

RECOVERY PENDING: Veri Sağlam, Etrafındaki Bir Şey Eksik

En çok yanlış anlaşılan ve en kolay kurtarılan durum budur. Microsoft’un tanımı açıktır: veritabanı hasarlı değildir; SQL Server recovery’yi başlatmaya çalışırken kaynakla ilgili bir hatayla karşılaşmıştır. Dosyalar eksik ya da erişilemez olabilir veya sistemin onları açmak için ihtiyaç duyduğu bir kaynak yoktur. Yapmanız gereken veritabanını “onarmak” değil, o eksik kaynağı bulmaktır.

Sahada karşılaştığımız gerçek sebepler

• Servis restart’ından sonra eksik kalan dosya izinleri. Instance çalışırken SQL Server servis hesabı değiştirilmiş ya da klasör izinleri daraltılmıştı. Hiçbir şey bozulmadı; ta ki bir sonraki restart’a kadar. O anda servis kendi data ve log dosyalarını açamaz hâle geldi.
• Replikasyonun doldurduğu disk. Replikasyon değişiklikleri iletemez olmuştu; bu yüzden transaction log yeniden kullanılamadı ve disk dolana kadar büyüdü. Sonraki açılışta recovery’yi tamamlayacak yer kalmamıştı. İpucu, yukarıdaki sorgudaki log_reuse_wait_desc = REPLICATION değeriydi.
• Değiştirilen sürücü harfleri. Bir müşterimiz sunucudaki sürücü harflerini yeniden atamıştı. Veritabanı dosyalarının hepsi yerli yerindeydi; sadece SQL Server’ın kayıtlı tuttuğu yollarda değillerdi.
• Sanallaştırma katmanında değişen disk düzeni. VMware yöneticileri SQL Server sanal makinesinin sanal disk / host bus ayarlarını değiştirmiş, açılışta diskler yer değiştirmiş sürücü harfleriyle gelmişti. Data diski log diskinin yerinde, log diski de data diskinin yerindeydi.

Ortak noktaya dikkat edin: hepsinde veritabanı sağlamdı. Çözüm tek bir onarım komutu çalıştırmak değil, ortamı SQL Server’ın beklediği hâle geri getirmekti.

Nasıl teşhis edip çözersiniz?

Önce SQL Server’ın dosyaları nerede beklediğini, diskte gerçekte ne olduğuyla karşılaştırın:

SELECT type_desc,
       name AS logical_name,
       physical_name,
       state_desc
FROM sys.master_files
WHERE database_id = DB_ID(N'VeritabaniAdi');

Sonra SQL Server’ın açılışta ne söylediğini okuyun. Error log neredeyse her zaman sorunlu dosyanın adını ve işletim sistemi hatasını (“access denied”, “the system cannot find the path specified” gibi) içerir. Error log okumaya yeniyseniz SQL Server error logları yazımız temel bilgileri veriyor.

-- Güncel error log, sadece veritabanı adını içeren mesajlar
EXEC sys.xp_readerrorlog 0, 1, N'VeritabaniAdi';

Asıl sebebi giderin: diski boşaltın ya da büyütün, sürücü harfini veya mount point’i geri getirin, servis hesabına klasör erişimi verin. Ardından SQL Server’ın recovery’yi yeniden denemesine izin verin:

ALTER DATABASE [VeritabaniAdi] SET OFFLINE;
ALTER DATABASE [VeritabaniAdi] SET ONLINE;

SUSPECT: Recovery Çalıştı ve Başarısız Oldu

SUSPECT, SQL Server’ın veritabanını kurtarmayı denediği ama başaramadığı anlamına gelir; en azından primary filegroup hasarlı olabilir. Verinizi koruyan şey burada işlemleri doğru sırayla yapmaktır.

1. Durun ve dosyaları kopyalayın. Herhangi bir onarım denemesinden önce veritabanına ait tüm dosyaların fiziksel kopyasını alın: .mdf, .ndf, .ldf, full-text kataloglar ve FILESTREAM klasörleri. Microsoft bunu onarımın ön koşulu olarak sayar; sonraki bütün seçenekleri açık tutan da budur.
2. Son sağlam yedeği bulun. Vakaların büyük çoğunluğunda doğru cevap yedekten dönmektir ve en hızlısı da odur. Adım adım SQL Server restore işlemi yazımız full, differential ve log restore’u anlatıyor.
3. EMERGENCY modunu “düzeltmek” için değil, veri kurtarmak için kullanın. Bir sysadmin veritabanını EMERGENCY moduna alabilir; veritabanı yalnızca sysadmin’ler için salt okunur hâle gelir. Son yedekten sonra değişen kritik tabloları dışarı almak için işe yarar.
4. REPAIR_ALLOW_DATA_LOSS seçeneğini en son çare olarak görün. Microsoft’un DBCC CHECKDB dokümanına göre bu seçenek, sağlam bir yedekten dönmekten daha fazla veri kaybettirebilir. Transaction log’u yeniden oluşturduğunda tam ACID garantisi kalmaz ve sonrasında kısıtları DBCC CHECKCONSTRAINTS ile doğrulamanız gerekir.

Yedek yetmediğinde

Bazen yedek vardır ama ihtiyacınız olan her şeyi içermez. Bir müşterimizin yedeklerinde full-text index’ler yoktu ve bunları sıfırdan oluşturmak kesinti süresine sığmıyordu. Ekibimiz hasarlı veritabanını onarmak yerine aynı dosya düzenine sahip geçici bir veritabanı oluşturdu, dosyalarını orijinal data dosyalarıyla değiştirdi ve veritabanını kontrollü bir şekilde ayağa kaldırdı. Böylece düz bir restore’un kaybettireceği full-text yapıları da kurtarıldı.

Bu yöntem, ekip her aşamada hangi adımın güvenli olduğunu bildiği için işe yaradı. Aynı teknik deneyimsiz ellerde denendiğinde, kurtarılabilir bir veritabanını kurtarılamaz hâle getirebilir. Bu vakanın tamamını ayrı bir başarı hikâyesi olarak yayınlayacağız.

RESTORING ve RECOVERING: Çoğu Zaman Sabır Meselesi

RESTORING çoğunlukla bir restore sırasının başlatıldığını ama WITH RECOVERY ile bitirilmediğini gösterir. Tek seferlik bir restore yapıyorsanız ve gereken tüm yedekler uygulandıysa işlemi tamamlayın:

RESTORE DATABASE [VeritabaniAdi] WITH RECOVERY;

RECOVERING, SQL Server’ın bir restart ya da failover sonrasında işlemleri yeniden uyguladığı ve geri aldığı anlamına gelir. Error log ilerlemeyi aşama ve yüzde olarak bildirir (“Recovery of database … is 42% complete”). Büyük ya da uzun süre açık kalmış transaction’lar bu aşamayı yavaşlatır. SQL Server 2019 ve sonrasında Accelerated Database Recovery bu süreyi ciddi ölçüde kısaltabilir; ihtiyaç duymadan önce açmaya değer.

Asla Yapmayın: Sahada Topladığımız Gerçek Hatalar

Bu listedeki her madde, bir olayı bizzat daha da kötüleştirdiğini gördüğümüz bir şey:

• Uzun süren bir transaction’ı kill ettikten sonra restart etmek. Büyük bir transaction’ı kill etmek rollback’i başlatır. Servisi yeniden başlatmak bu işi atlatmaz: veritabanı açılmadan önce recovery’nin rollback’i bitirmesi gerekir ve artık her şey onu bekler. İlerlemeyi KILL <session_id> WITH STATUSONLY ile izleyin ve bitmesine izin verin.
• Senkronize olmaya çalışan bir replikayı restart etmek. Bir sistem yöneticisi, replikasyon ortamında senkronizasyonu süren bir node’u yeniden başlattı ve saatlerce süren ilerleme sıfıra döndü.
• SQL Server sanal makinesini silmek. Evet, gerçekten; hem de birden fazla kez. “Yeniden kurarız” demek, kurtarma için gereken dosyaların ta kendisini yok eder.
• Yer açmak için .ldf dosyasını silmek. Log dosyası geçici bir dosya değildir. O olmadan, rahatlıkla kurtarılabilecek bir veritabanı doğrudan SUSPECT’e düşebilir.
• Hasarlı veritabanını “temiz attach etmek” için detach etmek. Attach için başarılı bir recovery gerekir; zaten başarısız olan da tam olarak budur. Attach edemediğiniz bir veritabanıyla çalışmak, SQL Server’ın hâlâ tanıdığı bir veritabanıyla çalışmaktan çok daha zordur.
• Tam anlamadığınız ayarları değiştirmek. Bir müşterimiz FILLFACTOR değerini “tamamen doldur” anlamına geldiğini düşünerek 1 yapmıştı. Oysa bu, her sayfanın yaklaşık %1 dolu bırakılması demek. Index’ler kat kat büyüdü; kontrolsüz dosya büyümesi de dolu bir diskin ve RECOVERY PENDING’e düşen bir veritabanının tam olarak başladığı yerdir.
• Restore yerine önce onarım yapmak. Sağlam bir yedeğiniz varsa ondan dönün. Onarım, hiçbir yedeğin işe yaramadığı durumlar içindir.
• Bir forumdan ya da yapay zekâ sohbetinden komut yapıştırmak. Öneri başka birinin ortamı için doğru olabilir. Ama sizin yedeklerinizi, topolojinizi ve neyin risk altında olduğunu bilmez.

Resmi Davranış, Aryasoft Saha Notları ve Bizim Önerimiz

Üç şeyi bilerek ayırıyoruz: Microsoft’un belgelediği, gerçek vakalarda gördüğümüz ve tavsiye ettiğimiz. Bunlara farklı ağırlıkla bakın.

Bir Daha Yaşamamak İçin

• DBCC CHECKDB‘yi düzenli çalıştırın; bozulmayı kullanıcılarınız değil, zamanlanmış bir job bulsun.
• Yedeklerinizi gerçekten restore ederek test edin. “Başarılı” biten bir backup job’ı yalnızca bir dosyanın yazıldığını kanıtlar.
• Boş disk alanını ve log_reuse_wait_desc değerini izleyin, özellikle replike edilen veritabanlarında.
• Altyapı ekibinizle anlaşın: SQL Server sunucularında depolama, sürücü harfi ve servis hesabı değişiklikleri önce DBA’den geçsin.
• Hasarlı sayfaların nereden geldiğini anlamak için SQL Server bozulması yazımıza göz atın.

Disiplinli bir kurtarmanın gerçek örneği için, hatalı bir restore sonrasında 1 dakikalık RPO ile nasıl kurtarma yaptığımızı okuyabilirsiniz.

Aryasoft Ne Kadar Hızlı Müdahale Eder?

Canlı ortamdaki bir veritabanı kapalıyken müdahale süresi çözümün bir parçasıdır. SLA hizmeti alan müşterilerimizin olayına mesai saatleri içinde 30 dakika, mesai saatleri dışında 2 saat içinde bir DBA müdahale eder. Bakım destek müşterilerimize ise mesai saatleri içinde 2 saat, mesai saatleri dışında 4 saat içinde müdahale ediyoruz.

Kaynaklar (Microsoft Learn)

Bu rehberdeki teknik iddialar 19 Ekim 2026 tarihinde aşağıdaki birincil kaynaklara karşı kontrol edildi. Microsoft dokümantasyonu her an değişebilir; üretimde değişiklik yapmadan önce sürüme özel ayrıntıları yeniden doğrulayın.

• Database states (İngilizce)
• ALTER DATABASE SET options: OFFLINE, ONLINE, EMERGENCY (İngilizce)
• DBCC CHECKDB: REPAIR_ALLOW_DATA_LOSS, emergency mode, CHECKCONSTRAINTS (İngilizce)
• KILL: WITH STATUSONLY (İngilizce)
• sys.databases: log_reuse_wait_desc (İngilizce)
• Accelerated database recovery (İngilizce)