SQL Veritabanı Kurtarma Bekliyor: 15 Kanıtlanmış Düzeltme [2026]

SQL veritabanınız kurtarma bekleme durumunda takılı kaldığında, veritabanınıza erişilemez hale gelir ve işlemler durur. Bu kapsamlı kılavuz, basit yeniden başlatmalardan gelişmiş acil onarımlara kadar SQL veritabanı kurtarma bekleme sorunlarını çözmek için kanıtlanmış 15 yöntem sunmaktadır.

1. SQL Veritabanı Kurtarma Bekleme Durumunu Anlama

Herhangi bir düzeltmeyi denemeden önce, SQL veritabanı kurtarma bekleyen sorunlarına neyin sebep olduğunu anlamak, doğru çözümü seçmek için çok önemlidir.

1.1 Kurtarma Bekliyor Ne Anlama Gelir?

Kurtarma bekleniyor, şunu gösterir: SQL Server Veritabanının kurtarılması gerektiğini algılar ancak kurtarma işlemine başlayamaz. Aktif kurtarma işleminin devam ettiğini gösteren "Kurtarılıyor" ifadesinin aksine, "Kurtarma Beklemede" ifadesi kurtarma işleminin bir engel nedeniyle bloke edildiği anlamına gelir.

Temel veritabanı durumları şunlardır:

ONLINE – Normal çalışma durumu
KURTARMA – Kurtarma işlemi aktif olarak çalışıyor
İYİLEŞME BEKLİYOR – Kurtarma işlemi başlatılamaz
ŞÜPHELİ – Veritabanında kritik hatalar var
ACİL SERVİS – Onarımlar için sınırlı salt okunur erişim
ÇEVRİMDIŞI – Manuel olarak çevrimdışı alındı

1.2 SQL Veritabanı Kurtarma Beklemesinin Yaygın Nedenleri

SQL veritabanı kurtarma bekleyen sorunları genellikle şu yaygın nedenlerden kaynaklanır:

Eksik veya bozuk işlem günlüğü dosyaları (LDF)
Kurtarma işlemleri sırasında yetersiz disk alanı
Donanım arızaları ve beklenmedik sistem kapanmaları
Bozuk MDF veritabanı dosyaları
Dosya izni sorunları erişimi engelliyor
SQL Server hizmet başlatma zamanlama sorunları
FILESTREAM yapılandırma hataları
Sunucu geçişlerinden sonra hatalı dosya yolları

1.3 Veritabanı Durumu Nasıl Kontrol Edilir

Veritabanınızın durumunu şu yöntemleri kullanarak doğrulayın:

kullanma SQL Server Yönetim Stüdyosu:

Bağlanın SQL Server örnek
Genişletmek veritabanları dosya
“(Kurtarma Bekliyor)” durumunu gösteren veritabanlarını arayın

T-SQL komutunu kullanarak:

SELECT name, state_desc FROM sys.databases WHERE state_desc = 'RECOVERY_PENDING';

2. İlk Tanısal Adımlar

Herhangi bir SQL veritabanı kurtarma işlemine başlamadan önce doğru tanı koymak çok önemlidir.

2.1 Kontrol SQL Server Hata günlükleri

Hata günlükleri, kurtarma bekleme durumuna neyin sebep olduğu hakkında önemli bilgiler içerir.

Açılış SQL Server Yönetim Stüdyosu
Şu yöne rotayı ayarla Yönetim -> SQL Server Kayıtlar
Son hataları görüntülemek için geçerli günlüğe çift tıklayın
Veritabanınızla ilgili hata mesajlarını arayın

Alternatif olarak T-SQL'i kullanabilirsiniz:

EXEC sp_readerrorlog;

2.2 Windows Olay Günlüklerini Kontrol Edin

Basın Windows Tuşu + R
Menşei eventvwr.msckutusuna ve Enter'a basın
Şu yöne rotayı ayarla Windows Günlükleri -> sistem hem de Uygulama
Aramak SQL Server sorun oluştuğu sırada ilgili hatalar

2.3 Dosya Erişilebilirliğini Doğrulayın

Veritabanı dosya konumlarınıza gidin
Hem MDF hem de LDF dosyalarının mevcut olduğunu doğrulayın
Sürücülerin çevrimiçi ve erişilebilir olup olmadığını kontrol edin
Ağ sürücülerinin düzgün şekilde bağlandığını onaylayın

3. Çözüm #1: Yeniden Başlatın SQL Server Hizmetler

Yeniden Başlatma SQL Server Bu hizmet, zamanlama sorunları veya geçici kaynak çakışmaları nedeniyle ortaya çıkan birçok SQL veritabanı kurtarma bekleme sorununu çözmektedir.

3.1 Servis Yeniden Başlatma İşlemi Ne Zaman Başarılı Olur?

Bu yöntem şu durumlarda etkilidir:

Başlangıç sırasında geçici kaynak kilitleri
Sürücü kullanılabilirliği gecikmelerini giderin
Hizmet bağımlılığı zamanlama sorunları
Küçük yapılandırma çakışmaları

3.2 Yeniden Başlatma Nasıl Yapılır SQL Server Hizmetler

Yöntem 1: SQL Server Yapılandırma yöneticisi

Açılış SQL Server Yapılandırma yöneticisi
Tıkla SQL Server Hizmetler
Sağ tıklayın. SQL Server örneğin, SQL Server (MSSQLSERVER)
Seç Yeniden
Servisin tamamen yeniden başlatılmasını bekleyin.

Yöntem 2: Hizmetler Konsolu

Basın Windows Tuşu + R
Menşei services.msc ve Enter'a basın
Bul SQL Server örneğin, SQL Server (MSSQLSERVER)
Sağ tıklayın ve seçin Yeniden

Yöntem 3: PowerShell

Restart-Service -Name "MSSQLSERVER" -Force

3.3 Yeniden Başlatma Sonrası Doğrulama

Başlatma işleminin tamamlanması için 2-3 dakika bekleyin.
SSMS'de veritabanı durumunu kontrol edin
Herhangi bir yeni mesaj için hata günlüklerini doğrulayın
Veritabanı bağlantısını test edin

4. Düzeltme #2: Disk Alanı Sorunlarını Kontrol Edin ve Çözün

Yetersiz disk alanı, SQL veritabanı kurtarma işlemlerinin beklemede kalmasının yaygın bir nedenidir. Kurtarma işlemleri, geçici dosyalar ve günlük dosyalarının büyümesi için ek alana ihtiyaç duyar.

4.1 Disk Alanı Sorunlarını Belirleme

Açılış dosya Gezgini
Veritabanı dosyalarını içeren sürücülere gidin
Mevcut boş alanı kontrol edin
Kurtarma işlemleri için en az %10-20 boş alan sağlayın

4.2 Disk Alanını Boşaltma

Gereksiz geçici dosyaları silin.
Şeffaf SQL Server alan açısından kritikse dosyaları yedekleyin
Gerekli olmayan dosyaları diğer sürücülere taşıyın
Mümkünse diğer veritabanı dosyalarını küçültün

Veritabanı dosyalarını küçültün (dikkatli kullanın):

DBCC SHRINKFILE (logicalfilename, target_size);

4.3 Boşluk Düzeltmesinden Sonra Veritabanını Çevrimiçi Ayarlama

Yer açıldığında veritabanını çevrimiçi hale getirmeyi deneyin:

ALTER DATABASE [DatabaseName] SET ONLINE;

5. Düzeltme #3: Ayarla SQL Server Hizmetin Gecikmeli Başlatılması

ayar SQL Server Gecikmeli başlatma, sistem önyüklemesi sırasında depolama sistemlerinin veya ağ sürücülerinin hazır olmamasından kaynaklanan SQL veritabanı kurtarma bekleme sorunlarını çözer.

5.1 Zamanlama Sorunlarını Anlama

Zamanlama sorunları şu durumlarda ortaya çıkar:

SAN veya ağ depolamasının başlatılması zaman alır
Sürücü harfleri erken önyükleme sırasında atanmaz
Ağ sürücüleri kimlik doğrulaması gerektirir
Depolama denetleyicilerinin başlatma süresine ihtiyacı vardır

5.2 Gecikmeli Başlatmanın Yapılandırılması

Basın Windows Tuşu + R
Menşei services.msc ve Enter'a basın
Bul SQL Server örneğin, SQL Server (MSSQLSERVER)
Sağ tıklayın ve seçin Emlaklar
Düzenle Başlangıç türü için Otomatik (Gecikmeli Başlatma)
Tıkla OK
Test etmek için sistemi yeniden başlatın.

5.3 Zamanlama İçin Alternatif Çözümler

Daha fazla kontrol için zamanlanmış bir görev oluşturun:

Açılış görev Zamanlayıcı
Tıkla Eylem -> Temel Görev Oluştur
Girişi İsim hem de Açıklama Görevin başlangıcını geciktir, örneğin "Görevin başlangıcını geciktir". SQL Server hizmet"
set Tetik için Bilgisayar başladığında
set Action için Başlangıç Programı
set Program / Komut tam yoluna Sqlservr.exe, şöyle: C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Binn\sqlservr.exe. Bunu bulmak için Windows'taki arama işlevini kullanabilirsiniz.
Bitiş sayfasında şunu seçin: Bitir'e tıkladığımda bu görev için Özellikler iletişim kutusunu aç.
Tıkla Bitiş.
Görev özellikleri iletişim kutusunda, tıklayın tetikleyiciler çıkıntı
Tetiği seçin ve tıklayın Düzenle
Gelişmiş ayarlarda, işaretleyin Görevi geciktir: ve süreyi 3 dakikaya ayarlayın.
Tıkla Tamam.

6. Düzeltme #4: Dosya İzinlerini ve Erişim Haklarını Düzeltin

İzin sorunları engelliyor SQL Server Veritabanı dosyalarına erişim engellenir ve bu da SQL veritabanı kurtarma bekleme durumlarına yol açar. Veritabanı işlemleri için uygun dosya izinleri şarttır.

6.1 Yaygın İzin Sorunları

SQL Server hizmet hesabında dosya erişim hakları eksik
Antivirüs yazılımı dosya erişimini engelliyor
Değiştirilen güvenlik politikaları
Ağ paylaşım izni sorunları

6.2 Klasör İzinlerini Düzeltme

Veritabanı dosya klasörüne gidin
Klasörü sağ tıklayın ve seçin Emlaklar
Tıkla Güvenlik çıkıntı
Tıkla Düzenle
Eklemek SQL Server eksikse hizmet hesabı
Hibe Tam Denetim izinleri
Tıkla OK değişiklikleri uygulamak

Komut Satırını (icacls) Kullanma:

icacls "C:\Data" /grant "NT SERVICE\MSSQLSERVER":F /T

6.3 Hizmet Hesabı Hususları

Doğrulayın. SQL Server hizmet hesabı:

Açılış SQL Server Yapılandırma yöneticisi
Tıkla SQL Server Hizmetler
Not Oturum Aç hesap için SQL Server
Bu hesabın uygun izinlere sahip olduğundan emin olun

7. Düzeltme #5: Manuel Dosya Yolu Düzeltmesi

Veritabanı dosyaları taşındığında veya sürücü harfleri değiştiğinde dosya yolu sorunları oluşur. Bu yöntem güncellenir SQL ServerGerçek dosyaları taşımadan 'nin dahili dosya referanslarını değiştirir.

7.1 Yol Sorunları Oluştuğunda

Sunucu donanım değişiklikleri
Sürücü harfi yeniden atamaları
Ağ yolu değişiklikleri
Veritabanı dosyası taşımaları

7.2 Dosya Yollarını Düzeltme

Hata günlüklerinde geçerli dosya yollarını belirleyin
Gerçek veritabanı dosyalarını bulun
Yolları güncellemek için ALTER DATABASE'i kullanın

Veri dosyası yolunu güncelle:

ALTER DATABASE [DatabaseName] 
MODIFY FILE (NAME = 'LogicalDataFileName', FILENAME = 'C:\NewPath\DatabaseName.mdf');

Günlük dosyası yolunu güncelle:

ALTER DATABASE [DatabaseName] 
MODIFY FILE (NAME = 'LogicalLogFileName', FILENAME = 'C:\NewPath\DatabaseName_Log.ldf');

7.3 Doğrulama Adımları

Yeniden SQL Server hizmet
Veritabanı durumunu kontrol edin
Yolla ilgili mesajlar için hata günlüklerini doğrulayın
Veritabanı bağlantısını test edin

8. Düzeltme #6: Veritabanını Çevrimdışı Yapın ve Sonra Çevrimiçi Hale Getirin

Bu basit durum değişikliği, temiz bir durum geçişi sağlayarak ve geçici kilitleri kaldırarak, SQL veritabanı kurtarma işleminde bekleyen küçük sorunları çözebilir.

8.1 Bu Yöntem Ne Zaman İşe Yarar?

Küçük devlet tutarsızlıkları
Geçici kaynak kilitleri
Basit kurtarma işlemi sıfırlanır
Kritik olmayan hata koşulları

8.2 Çevrimdışı/Çevrimiçi Prosedür

Veritabanına etkin bağlantı olmadığından emin olun
Çevrimdışı komutunu yürütün
Birkaç saniye bekleyin
Çevrimiçi komutu yürütün

Güvenli yöntem (bağlantıların kapanmasını bekler):

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

Hemen yöntem (bağlantıları sonlandırır):

ALTER DATABASE [DatabaseName] SET OFFLINE WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [DatabaseName] SET ONLINE;

8.3 Riskler ve Hususlar

Uyarı: ROLLBACK IMMEDIATE kullanımı, işlenmemiş işlemlerden kaynaklanan veri kaybına neden olabilir. Yalnızca gerekli olduğunda kullanın ve kullanıcıların oturumlarının kapalı olduğundan emin olun.

9. Düzeltme #7: OTOMATİK KAPATMA Özelliğini Devre Dışı Bırakın

Veritabanları sık sık açılıp kapandığında OTOMATİK KAPATMA özelliği SQL veritabanı kurtarma bekleme sorunlarına neden olabilir ve kurtarma işlemleri sırasında zamanlama çakışmaları yaratabilir.

9.1 OTOMATİK KAPANMA Etkisini Anlama

Son kullanıcı bağlantısını kestikten sonra veritabanı kapanıyor
Veritabanı her açıldığında kurtarılmalıdır
Sık kurtarma döngüleri oluşturur
Diğer operasyonlara müdahale edebilir

9.2 OTOMATİK KAPATMA'yı devre dışı bırakma

T-SQL Kullanımı:

ALTER DATABASE [DatabaseName] SET AUTO_CLOSE OFF;

kullanma SQL Server Yönetim Stüdyosu:

Veritabanına sağ tıklayın
Seç Emlaklar
MyCAD'de yazılım Güncelleme ye git Seçenekler Kanal
set Otomatik kapanma için Yanlış
Tıkla OK

9.3 İlgili OTO Ayarları

Daha iyi performans için AUTO_SHRINK özelliğini devre dışı bırakmayı da düşünün:

ALTER DATABASE [DatabaseName] SET AUTO_SHRINK OFF;

10. Çözüm #8: Bozuk Günlük Dosyasını Silin ve Yeniden Başlatın

Bu yöntem, işlem günlüğü dosyası onarılamayacak kadar ciddi şekilde bozulduğunda işe yarar. Yalnızca geliştirme ortamlarında veya veri kaybının kabul edilebilir olduğu durumlarda kullanılmalıdır.

10.1 Günlük Silinmesinin Uygun Olduğu Durumlar

⚠️ KRİTİK UYARI: Bu yöntem veri kaybına neden olur!

Yalnızca şu durumlarda kullanın:

Geliştirme/test veritabanlarıyla çalışma
Günlük dosyası tamamen bozulmuş
Başka kurtarma seçeneği mevcut değil
Son yedeklemeler mevcuttur

10.2 Günlük Dosyası Silme Prosedürü

dur SQL Server tamamen hizmet
Veritabanı dosya konumuna gidin
.LDF dosyasını silin (.MDF dosyasını saklayın)
Ana Sayfa SQL Server hizmet
SQL Server otomatik olarak yeni bir günlük dosyası oluşturacaktır

10.3 Önemli Uyarılar

Veri Kaybının Sonuçları:

Tamamlanmamış tüm işlemler kalıcı olarak kaybolur.
Günlük zinciri bozuk - diferansiyel yedeklemeler geçersiz
Belirli bir noktada kurtarma imkansız hale gelir
Yalnızca üretim dışı ortamlarda kullanın

11. Düzeltme #9: Veritabanını Ayırın ve Yeniden Bağlayın

Kuvvetlerin ayrılması ve yeniden bağlanması SQL Server Eksik veya bozuk günlük dosyalarını yeniden oluşturmak için. Bu yöntem, günlük dosyaları sorunlu olduğunda SQL veritabanı kurtarma bekleyen sorunlarını çözebilir.

11.1 Ayır/Tekrar Tak Ne Zaman Çalışır?

Eksik günlük dosyaları
Bozuk günlük dosyası başlıkları
Günlük dosyası yolu değişiklikleri
Basit yolsuzluk senaryoları

11.2 Standart Çıkarma/Tekrar Takma Prosedürü

Önce veritabanını acil durum moduna ayarlayın
Çok kullanıcılı moda geç
Veritabanını ayırın
Yalnızca MDF dosyasını kullanarak yeniden ekleyin

-- Set to emergency mode
ALTER DATABASE [DatabaseName] SET EMERGENCY;
ALTER DATABASE [DatabaseName] SET MULTI_USER;

-- Detach database
EXEC sp_detach_db '[DatabaseName]';

-- Re-attach with single file (MDF only)
EXEC sp_attach_single_file_db 
    @DBName = '[DatabaseName]', 
    @physname = N'C:\Data\DatabaseName.mdf';

11.3 Alternatif Bağlantı Yöntemleri

Birden fazla dosya senaryosu için:

CREATE DATABASE [DatabaseName] 
ON (FILENAME = 'C:\Data\DatabaseName.mdf'),
   (FILENAME = 'C:\Data\DatabaseName_2.ndf')
FOR ATTACH;

12. Düzeltme #10: İşlem Günlüğü Dosyalarını Yeniden Oluşturun

Günlük yeniden oluşturma, orijinali eksik veya onarılamayacak şekilde hasar görmüşse yeni bir işlem günlüğü dosyası oluşturur. Bu yöntem, SQL veritabanı kurtarma bekleyen sorunlarını çözer ancak veri kaybına neden olur.

12.1 Günlük Yeniden Oluşturma Ne Zaman Gereklidir?

Donanım arızasından sonra eksik LDF dosyaları
Ciddi şekilde bozulmuş işlem günlükleri
Düzeltilemeyen günlük dosyası yolu değişiklikleri
Acil kurtarma durumları

12.2 Günlük Yeniden Oluşturma Süreci

⚠️ UYARI: Bu durum veri kaybına neden olur!

Veritabanını acil durum moduna ayarlayın
REBUILD LOG komutunu kullanın
Yeni günlük dosyası konumunu belirtin
Veritabanını çevrimiçi hale getirin

ALTER DATABASE [DatabaseName] SET EMERGENCY;
GO

ALTER DATABASE [DatabaseName] REBUILD LOG ON 
(NAME = 'DatabaseName_Log', FILENAME = 'C:\Logs\DatabaseName_Log.ldf');
GO

ALTER DATABASE [DatabaseName] SET ONLINE;
GO

12.3 Veri Kaybının Etkilerini Anlama

Günlük yeniden oluşturmanın nedenleri:

Taahhüt edilmemiş tüm işlemlerin kaybı
Kırık günlük sıra numaraları
Sonraki günlük yedeklerinin uygulanamaması
Belirli bir noktada kurtarma imkansız hale gelir

13. Düzeltme #11: Acil Durum Modu Onarımı DBCC KONTROL DB'si

Acil durum modu onarımı, bozulma nedeniyle oluşan bekleyen SQL veritabanı sorunlarını kurtarmak için son çare yöntemidir. Bu yöntem veritabanlarını onarabilir, ancak önemli veri kayıplarına neden olabilir.

13.1 Acil Durum Modunu Anlama

⚠️ SON UYARI: Veri kaybı riski yüksek!

Acil durum modunu yalnızca şu durumlarda kullanın:

Diğer tüm yöntemler başarısız oldu
Yakın zamanda yapılmış yedekleme yok
Bazı verileri kurtarmak, tüm verileri kaybetmekten daha iyidir
Veritabanı kritik derecede bozulmuş

13.2 Acil Onarım Prosedürü

Öncelikle bozuk veritabanı dosyalarının yedeğini alın
Veritabanını acil durum moduna ayarlayın
Tek kullanıcı moduna geç
CHECKDB'yi onarım seçeneğiyle çalıştırın
Çok kullanıcılı moda dön

-- Step 1: Set to emergency mode
ALTER DATABASE [DatabaseName] SET EMERGENCY;
GO

-- Step 2: Single user mode
ALTER DATABASE [DatabaseName] SET SINGLE_USER;
GO

-- Step 3: Repair with no data loss
DBCC CHECKDB ([DatabaseName], REPAIR_REBUILD) WITH ALL_ERRORMSGS;
GO

-- Step 4: Return to multi-user
ALTER DATABASE [DatabaseName] SET MULTI_USER;
GO

13.3 Onarım Sonrası Değerlendirme

Onarım eylemleri için CHECKDB çıktısını inceleyin
Eksik tabloları veya verileri kontrol edin
Kritik uygulama işlevselliğini doğrulayın
Çok fazla veri kaybı yaşanması durumunda yedeklemeden geri yüklemeyi düşünün.

14. Düzeltme #12: FILESTREAM Yapılandırmasını Kontrol Edin ve Düzeltin

FILESTREAM yapılandırma sorunları, SQL veritabanı kurtarma bekleme sorunlarına neden olabilir. Bu yöntem, FILESTREAM'e özgü kurtarma hatalarını ele alır.

14.1 FILESTREAM ile İlgili Kurtarma Sorunları

FILESTREAM sürücüsü bağlantı hataları
Yapılandırma uyumsuzlukları arasında SQL Server ve işletim sistemi
Hizmet başlatma sırasında zamanlama sorunları
FILESTREAM kapsayıcılarında izin sorunları

14.2 FILESTREAM Sorun Giderme

FILESTREAM yapılandırma düzeyini kontrol edin
Windows özelliğinin etkinleştirildiğini doğrulayın
Gerekli hizmetlerin yeniden başlatılması gerekiyor.
FILESTREAM kapsayıcı izinlerini kontrol edin

FILESTREAM yapılandırmasını kontrol edin:

SELECT SERVERPROPERTY('FilestreamEffectiveLevel') AS CurrentLevel;

Örnek düzeyinde FILESTREAM'i etkinleştirin:

EXEC sp_configure 'filestream access level', 2;
RECONFIGURE;

14.3 FILESTREAM En İyi Uygulamaları

Yeniden başlatmalar arasında tutarlı bir yapılandırma sağlayın.
FILESTREAM kapsayıcı yollarının erişilebilir olduğunu doğrulayın
Windows FILESTREAM özelliğinin düzgün şekilde etkinleştirildiğini kontrol edin
FILESTREAM ile ilgili hata mesajlarını izleyin

15. Düzeltme #13: Güncelleme SQL Server Sürüm/Hizmet Paketleri

Büyük SQL Server Özellikle RTM sürümleri, SQL veritabanı kurtarma bekleyen sorunlarına neden olan bilinen hatalar içerir. En son hizmet paketlerine güncelleme yapmak bu sorunları çözer.

15.1 Eski Sürümlerdeki Bilinen Sorunlar

SQL Server 2005 RTM kurtarma hataları
Kurtarma işlemleri için hizmet paketine özgü düzeltmeler
Uç durumları ele alan kümülatif güncellemeler
Daha yeni Windows sürümleriyle uyumluluk sorunları

15.2 Güncelleme Süreci

Akımı kontrol et SQL Server versiyon
Mevcut en son hizmet paketini belirleyin
Indirin Microsoft Yükleme Merkezi
Bakım penceresini planlayın
Hizmet paketini yükleyin
Hizmetleri yeniden başlat
Veritabanı işlevselliğini doğrulayın

Güncel sürümü kontrol edin:

SELECT @@VERSION;

15.3 Güncelleme Sonrası Doğrulama

Sürüm numarasının değiştirildiğini onaylayın
Tüm veritabanlarının düzgün bir şekilde çevrimiçi olduğunu kontrol edin
Temel işlevsellik testlerini çalıştırın
Herhangi bir yeni sorun olup olmadığını görmek için hata günlüklerini izleyin

16. Düzeltme #14: Veritabanını Yedekten Geri Yükleme

SQL veritabanı kurtarma işlemleri onarım yöntemleriyle çözülemediğinde, bilinen sağlam bir yedeklemeden geri yükleme, öngörülebilir veri kaybı sınırlarıyla en güvenilir çözümü sunar.

16.1 Yedekleme Geri Yükleme Çözüm Olduğunda

Birden fazla onarım girişimi başarısız oldu
Kritik üretim verileri kesinlik gerektirir
Kabul edilebilir veri kaybı penceresi mevcuttur
Yolsuzluk onarılamayacak kadar kapsamlı

16.2 Tam Veritabanı Geri Yükleme İşlemi

En son kullanılabilir yedeklemeyi belirleyin.
Geri yükleme için yeterli disk alanı sağlayın
Gerekirse veritabanını çevrimdışı yapın veya bırakın
Yedekleme dosyasından geri yükle
Mümkünse günlük yedeklerini uygulayın

Tam yedeklemeden temel geri yükleme:

RESTORE DATABASE [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName.bak'
WITH REPLACE;

Noktasal kurtarma için günlük yedekleriyle geri yükleme:

RESTORE DATABASE [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName.bak'
WITH NORECOVERY, REPLACE;

RESTORE LOG [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName_Log.trn'
WITH RECOVERY;

16.3 Doğrulama ve Test

Veritabanının başarıyla çevrimiçi olduğunu doğrulayın
CHECKDB ile veri bütünlüğünü kontrol edin
Kritik uygulama işlevlerini test edin
Yedekleme/geri yüklemenin hatasız tamamlandığını onaylayın

16.4 Referans

Daha fazla bilgiyi şuradan öğrenebilirsiniz: yedekleme ve geri yükleme hakkında kapsamlı kılavuz SQL Server veritabanları.

17. Düzeltme #15: Profesyonel SQL Kurtarma Araçları

SQL veritabanı kurtarma bekleyen sorunlarını çözmek için manuel yöntemler başarısız olduğunda, özel kurtarma yazılımları, standart yöntemlerle onarılamayan ciddi şekilde bozulmuş veritabanlarından verileri çıkarabilir.

17.1 Üçüncü Taraf Araçlarını Ne Zaman Düşünmelisiniz?

Manuel onarım yeteneklerinin ötesinde ciddi bozulma
Kullanılabilir yedeklemesi olmayan kritik veriler
Birden fazla başarısız manuel onarım girişimi
Zaman açısından kritik kurtarma gereksinimleri

17.2 DataNumen SQL Recovery

DataNumen SQL Recovery güçlü SQL Server veritabanı kurtarma aracı.

Kullanım adımları şu şekildedir:

Durdur SQL Server Hizmet.
Kurtarma bekleyen durumdaki veritabanı dosyalarının, hem birincil MDF dosyası hem de ikincil NDF dosyaları dahil olmak üzere bir kopyasını oluşturun.
Başlat SQL Server Hizmet.
Ana Sayfa DataNumen SQL Recovery.
Kurtarılacak veritabanının kaynağı olarak orijinal dosya yerine kopyayı seçin.
Veritabanını kurtarmak için "Kurtarmayı Başlat" seçeneğine tıklayın ve talimatları izleyin.
Kurtarma işleminin ardından yeni bir kurtarma veritabanı görünecektir. SQL Server kurtarılan tüm verileri içeren.

18. Gelişmiş Sorun Giderme Senaryoları

Karmaşık ortamlar, SQL veritabanı kurtarma bekleyen sorunlarını çözmek için özel yaklaşımlar gerektirir.

18.1 Çoklu Veritabanı Dosyaları Sorunları

Birden fazla veri dosyası (NDF) içeren veritabanları dikkatli bir şekilde ele alınmalıdır:

Hangi dosya gruplarının etkilendiğini belirleyin
Erişilebilirlik için tüm NDF dosyalarını kontrol edin
Dosya grubuna özgü kurtarma seçeneklerini göz önünde bulundurun
Salt okunur dosya gruplarını uygun şekilde işleyin

18.2 Her Zaman Açık Kullanılabilirlik Grupları

SQL veritabanı kurtarma işlemi beklemede her zaman Açık ortamları:

Önce birincil çoğaltma durumunu kontrol edin
Senkronizasyon durumunu doğrulayın
Sorunlu kopyayı kaldırmayı ve yeniden eklemeyi düşünün
Kullanılabilirlik grubu yapılandırmasını gözden geçirin

18.3 Küme ve Yüksek Erişilebilirlik Senaryoları

SQL veritabanı kurtarma işlemi beklemede yük devretme kümesi hem de yüksek kullanılabilirlik senaryolar:

Paylaşılan depolama erişilebilirliğini doğrulayın
Küme düğümü iletişimlerini kontrol edin
Yük devretme kümesi günlüklerini inceleyin
Uygun DNS çözümlemesini sağlayın

18.4 WMI ve Sistem Düzeyindeki Sorunlar

Sistem düzeyindeki sorunlar veritabanı sorunlarına yol açabilir:

WMI deposu bozulması
Başarısız Windows güncellemeleri
kayıt bozulması
Hizmet bağımlılığı sorunları

19. Önleme Stratejileri

SQL veritabanı kurtarma bekleyen sorunları önlemek, sorunlar oluştuktan sonra düzeltmekten daha etkilidir.

19.1 Yedekleme En İyi Uygulamaları

Otomatik tam yedekleme planlarını uygulayın
Düzenli diferansiyel yedeklemeleri yapılandırın
Sık sık işlem günlüğü yedeklemeleri ayarlayın
Yedekleme geri yükleme prosedürlerini düzenli olarak test edin
Yedekleri ayrı depolama sistemlerinde saklayın
Yedekleme bütünlüğünü RESTORE VERIFYONLY ile doğrulayın

19.2 İzleme ve Bakım

Disk alanı izleme uyarılarını ayarlayın
Düzenli DBCC CHECKDB operasyonlarını planlayın
İzliyoruz SQL Server günlük hata kayıtları
Uygulamak performans temel izleme
yapılandırma SQL Server Kritik hatalar için aracı uyarıları

19.3 Altyapı Hususları

Güç koruması için UPS sistemleri kurun
Yedeklilik ile kurumsal düzeyde depolama kullanın
Uygun kapatma prosedürlerini uygulayın
Paylaşılan depolama için ağ kararlılığını sağlayın
Düzenli donanım sağlığı izleme

19.4 SQL Server Yapılandırma En İyi Uygulamaları

Uygun kurtarma modellerini seçin
Mantıklı otomatik büyüme ayarlarını yapılandırın
Farklı sürücülerdeki ayrı veri ve günlük dosyaları
Minimum ayrıcalıklara sahip özel hizmet hesaplarını kullanın
tutmak SQL Server en son hizmet paketleriyle güncellendi

20. Sorun Giderme Karar Ağacı ve Metodolojisi

SQL veritabanı kurtarma bekleyen sorunlarıyla karşılaştığınızda bu sistematik yaklaşımı izleyin.

20.1 Sistematik Tanı Yaklaşımı

Önce hata günlüklerini kontrol edin – Her zaman şununla başlayın: SQL Server ve Windows günlükleri
Dosya erişilebilirliğini doğrulayın – Tüm veritabanı dosyalarının mevcut olduğundan ve okunabilir olduğundan emin olun
Disk alanını kontrol edin – Kurtarma operasyonları için yeterli alanın onaylanması
Önce basit düzeltmeleri deneyin – Hizmetin yeniden başlatılması, çevrimdışı/çevrimiçi
Karmaşık onarımlara doğru ilerleme – Sadece basit yöntemler başarısız olduktan sonra
Yedeklemeden geri yüklemeyi düşünün – Onarım riskleri çok yüksek olduğunda

20.2 Doğru Düzeltme Yöntemini Seçme

Düşük Risk (Önce Deneyin):

Yeniden SQL Server Hizmetler
Disk alanını kontrol edin ve çözün
Dosya izinlerini düzeltin
Çevrimdışı/Çevrimiçi veritabanı

Orta risk:

Dosya yolu düzeltmeleri
OTOMATİK KAPATMA'yı devre dışı bırak
FILESTREAM yapılandırma düzeltmeleri
Hizmetin başlatılmasında gecikme yaşandı.

Yüksek Risk (Veri Kaybı Olasılığı):

Günlük dosyasını silin ve yeniden başlatın.
Veritabanını ayır/yeniden ekle
İşlem günlüklerini yeniden oluştur
Acil durum modu onarımı ile DBCC KONTROL DB'si

20.3 Ne Zaman Yükseltilmeli

Aşağıdaki durumlarda profesyonel yardım alın:

Birçok yüksek riskli yöntem başarısız oldu
Veritabanı yeri doldurulamaz kritik veriler içeriyor
Bozulma birden fazla veritabanını etkiliyor
Sistem düzeyinde sorunlardan şüpheleniliyor
Zaman kısıtlamaları garantili sonuçlar gerektirir

21. SSS

S: “RECOVERING” ve “RECOVERY PENDING” veritabanı durumları arasındaki fark nedir?

A: "KURTARMA", veritabanının kurtarma işlemlerini aktif olarak gerçekleştirdiği ve tamamlandığında otomatik olarak çevrimiçi olacağı anlamına gelir. "KURTARMA BEKLEYEN", SQL Server Dosya eksikliği, yetersiz alan veya bozulma gibi bir engel nedeniyle kurtarma işlemi başlatılamıyor. Kurtarma işlemi beklemede olup, çözülmesi için manuel müdahale gerekmektedir.

S: SQL veritabanı kurtarma bekleyen sorunlarıyla karşılaştığımda öncelikle hangi düzeltmeyi denemeliyim?

A: Her zaman önce en güvenli yöntemlerle başlayın. Kontrol edin. SQL Server Hata günlüklerini kontrol edin, disk alanının kullanılabilirliğini doğrulayın, ardından yeniden başlatmayı deneyin. SQL Server Bu düşük riskli yaklaşımlar, veri kaybı riski olmadan en sık karşılaşılan kurtarma sorunlarını çözmektedir.

S: Başka bir düzeltme yöntemini denemeden önce ne kadar beklemeliyim?

A: Servis yeniden başlatmaları için, tam başlatma işlemi için 2-3 dakika bekleyin. Çevrimdışı/çevrimiçi gibi basit durum değişiklikleri için 30-60 saniye bekleyin. DBCC CHECKDB gibi karmaşık onarımlar için, veritabanı boyutuna bağlı olarak birkaç saat bekleyin. Kurtarma işlemleri başladıktan sonra bunları kesmeyin.

S: SQL veritabanı kurtarma bekleyen sorunlarını düzeltirken veri kaybeder miyim?

A: Veri kaybı kullanılan yönteme bağlıdır. Servis yeniden başlatma, disk alanı düzeltmeleri ve izin düzeltmeleri gibi güvenli yöntemler veri kaybına neden olmaz. Acil durum modu onarımı, günlük yeniden oluşturma veya günlük dosyalarını silme gibi yüksek riskli yöntemler önemli veri kaybına yol açabilir. Her zaman önce güvenli yöntemleri deneyin.

S: SQL veritabanı kurtarma bekleyen sorunlarının oluşmasını engelleyebilir miyim?

A: Evet, çoğu sorun doğru bakım ile önlenebilir. Düzenli yedeklemeler yapın, disk alanını izleyin, yeterli depolama kapasitesi sağlayın, UPS koruması kullanın, rutin DBCC CHECKDB işlemlerini gerçekleştirin ve bakımını düzenli tutun. SQL Server en son servis paketleriyle güncellendi.

S: Üretim veritabanlarında onarımları iş saatleri içerisinde mi yapmalıyım?

A: Çalışma saatleri içinde üretim veritabanlarında yüksek riskli onarım yöntemlerini asla denemeyin. Karmaşık onarımlar için bakım pencereleri planlayın. Ancak, kritik işlemleri engelliyorsa, hizmet yeniden başlatma veya disk alanı düzeltmeleri gibi güvenli yöntemler hemen denenebilir.

S: Onarım yapmayı denemek yerine yedeklemeden geri yüklemeyi ne zaman yapmalıyım?

A: Birden fazla onarım girişimi başarısız olduğunda, daha fazla bozulma riski olmayan kritik üretim verileriyle uğraşırken, kabul edilebilir veri kaybı aralıklarına sahip yeni yedeklemeleriniz olduğunda veya onarım yöntemlerinin geri yükleme işlemlerinden daha uzun süreceği durumlarda yedeklemeden geri yükleyin.

S: Veritabanı dosyalarımın bozulduğunu veya erişilemez durumda olduğunu nasıl anlarım?

Kontrol SQL Server Belirli hata mesajları için hata günlükleri. Dosya erişilebilirlik sorunları "dosya bulunamadı" veya izin hatalarını gösterir. Bozulma genellikle sağlama toplamı hataları, sayfa düzeyinde hatalar veya tutarlılık ihlallerini gösterir. Veritabanı erişilebilir olduğunda bozulmayı kesin olarak test etmek için DBCC CHECKDB kullanın.

S: Veritabanı dosyalarını onarmaya çalışmadan önce kopyalamanın en güvenli yolu nedir?

A: Dur SQL Server hizmetini tamamen kapatın, ardından hem MDF hem de LDF dosyalarını bir yedekleme konumuna kopyalayın. Alternatif olarak, veritabanına hala erişilebiliyorsa veritabanı yedekleme komutlarını kullanın. Dosyaları asla SQL Server tutarsız kopyalar oluşturabileceğinden çalıştırılıyor.

S: SQL veritabanı kurtarma bekleyen sorunları aynı anda birden fazla veritabanını etkileyebilir mi?

A: Evet, yetersiz disk alanı, hizmet hesabı sorunları, depolama arızaları veya benzeri sistem düzeyindeki sorunlar SQL Server Yapılandırma hataları birden fazla veritabanını etkileyebilir. Daha geniş sistem sorunlarını belirlemek için diğer veritabanlarında da benzer sorunlar yaşanıp yaşanmadığını kontrol edin.

S: Veritabanı geri yükleme prosedürlerimi ne sıklıkla test etmeliyim?

A: Kritik veritabanları için aylık, önemli veritabanları için üç aylık geri yükleme prosedürlerini test edin. Noktasal kurtarma, günlük dizisi geri yükleme ve acil durum geri yükleme prosedürleri gibi farklı geri yükleme senaryolarını test etmeyi de ekleyin. Acil durum planlaması için her testi belgelendirin ve zamanlayın.

S: Microsoft Destek ile ne zaman iletişime geçmeliyim veya profesyonel yardım almalıyım?

A: Birden fazla onarım girişiminin başarısız olması, yedekleme olmadan kritik öneme sahip verilerle uğraşılması, birden fazla veritabanında karmaşık bozulmalarla karşılaşılması, belgelenmemiş hata mesajlarıyla karşılaşılması veya zaman kısıtlamalarının garantili kurtarma sonuçları gerektirmesi durumunda profesyonel yardım alın.

S: Üçüncü taraf SQL kurtarma araçları yatırıma değer mi?

A: Kurtarma araçları, manuel yöntemler başarısız olduğunda ve yedekleme bulunmadığında değerlidir. Çoğu araç, satın almadan önce kurtarılabilirliği test etmek için ücretsiz deneme sürümleri sunar. Maliyeti, profesyonel hizmetleri, veri değerini ve başarı olasılığını göz önünde bulundurun. Araçlar yapısal bozulmalar için en iyi sonucu verir, ancak tüm veri türlerini kurtaramayabilir.

S: SQL veritabanı kurtarma işlemi tekrar tekrar devam ederse ne yapmalıyım?

C: Tekrarlayan sorunlar, altta yatan sistem sorunlarını gösterir. Donanım arızaları, yetersiz kaynaklar, depolama sistemi sorunları veya yapılandırma sorunları olup olmadığını kontrol edin. Windows Olay Günlüklerini izleyin, kapsamlı izleme uygulayın ve donanımı yükseltmeyi veya daha güvenilir depolama sistemlerine geçmeyi düşünün.

22. Sonuç ve Hızlı Referans

SQL veritabanı kurtarma bekleme sorunları, basit hizmet yeniden başlatmalarından karmaşık acil onarımlara kadar uzanan bu 15 kanıtlanmış yöntem kullanılarak çözülebilir.

22.1 Hızlı Düzeltme Özet Tablosu

Düzeltme Yöntemi	Risk seviyesi	Veri Kaybı Riski	En İyi Kullanım İçin
Yeniden SQL Server	Düşük	Hayır	Zamanlama sorunları, geçici kilitler
Disk alanını kontrol edin	Düşük	Hayır	Uzayla ilgili arızalar
Rötar	Düşük	Hayır	Depolama zamanlama sorunları
Düzeltme izinleri	Düşük	Hayır	Erişim engellendi hataları
Doğru dosya yolları	Düşük	Hayır	Yol değişiklikleri, göçler
Çevrimdışı Çevrimiçi	Orta	asgari	Devlet tutarsızlıkları
OTOMATİK KAPATMA'yı devre dışı bırak	Düşük	Hayır	Sık sık açma/kapama döngüleri
Günlük dosyasını sil	Yüksek	Evet	Bozuk günlükler, geliştirme ortamları
Çıkar/tekrar tak	Yüksek	Evet	Eksik veya bozuk günlükler
Günlükleri yeniden oluştur	Yüksek	Evet	Eksik LDF dosyaları
DBCC CHECKDB ile acil onarım	Çok Yüksek	Evet	Ağır yolsuzluk, son çare
FILESTREAM'i düzeltin	Orta	Hayır	FILESTREAM yapılandırma sorunları
Güncelle SQL Server	Orta	Hayır	Bilinen sürüm hataları
Yedekten geri yükle	Düşük	Kontrollü	Onarım yöntemleri başarısız olduğunda
Kurtarma araçları	Orta	Değişir	Ciddi yolsuzluk, yedek yok

22.2 Acil Durum Müdahale Kontrol Listesi

İlk 5 Dakika:

Kontrol SQL Server hata günlükleri
Veritabanı dosyasının erişilebilirliğini doğrulayın
Kullanılabilir disk alanını kontrol edin
Hizmeti yeniden başlatmayı deneyin
Belge hata mesajları

Sonraki 15 Dakika:

Hizmet yeniden başlatma işlemi başarısız olursa çevrimdışı/çevrimiçi olarak tekrar deneyin.
Bariz izin sorunlarını kontrol edin ve düzeltin
Dosya yollarının doğru olduğunu doğrulayın
Windows olay günlüklerini inceleyin
Yedekleme kullanılabilirliğini değerlendirin

22.3 Ek Kaynaklar

Unutmayın: Uygun yedeklemeler, izleme ve bakım yoluyla önleme, kurtarmadan her zaman daha iyidir. Bu prosedürlerin üretim dışı ortamlarda düzenli olarak test edilmesi, SQL veritabanı kurtarma bekleyen sorunları ortaya çıktığında hazırlıklı olmanızı sağlar.

Yazar Hakkında

Yuan Sheng 10 yılı aşkın deneyime sahip kıdemli bir veritabanı yöneticisidir (DBA) SQL Server ortamlar ve kurumsal veritabanı yönetimi alanında uzmanlaşmıştır. Finansal hizmetler, sağlık ve üretim sektörlerindeki yüzlerce veritabanı kurtarma senaryosunu başarıyla çözmüştür.

Yuan şu konuda uzmanlaşmıştır: SQL Server Veritabanı kurtarma, yüksek erişilebilirlik çözümleri ve performans optimizasyonu alanlarında kapsamlı uygulamalı deneyime sahiptir. Terabaytlarca veri tabanını yönetme, Always On Kullanılabilirlik Grupları uygulama ve kritik öneme sahip iş sistemleri için otomatik yedekleme ve kurtarma stratejileri geliştirme konularında kapsamlı uygulamalı deneyime sahiptir.

Yuan, teknik uzmanlığı ve pratik yaklaşımıyla, veritabanı yöneticilerinin ve BT profesyonellerinin karmaşık sorunları çözmelerine yardımcı olan kapsamlı kılavuzlar oluşturmaya odaklanıyor. SQL Server Zorlukları verimli bir şekilde çözer. En son gelişmelerle güncel kalır. SQL Server Microsoft'un gelişen veritabanı teknolojilerini ve sürümlerini takip ederek, önerilerinin gerçek dünyadaki en iyi uygulamaları yansıttığından emin olmak için kurtarma senaryolarını düzenli olarak test ediyor.

hakkında sorularınız var SQL Server Kurtarma veya ek veritabanı sorun giderme kılavuzuna mı ihtiyacınız var? Yuan memnuniyetle karşılar geri bildirim ve öneriler Bu teknik kaynakların iyileştirilmesi için.

SQL Veritabanı Kurtarma Bekliyor: 15 Kanıtlanmış Düzeltme [2026 Rehberi]