SQL Server: Veritabanı "Geri Yükleniyor" durumunda kaldı


564

Bir veritabanını yedekledim:

BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing

Ve sonra geri yüklemeye çalıştı:

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE --force restore over specified database

Ve şimdi veritabanı geri yükleme durumunda kalmış.

Bazı insanlar bunun yedekte günlük dosyası bulunmadığı ve aşağıdakileri kullanarak ileriye doğru döndürülmesi gerektiği için teori oluşturdu:

RESTORE DATABASE MyDatabase
WITH RECOVERY 

Tabii ki, başarısız:

Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Ve felaket bir durumda tam olarak istediğiniz şey, işe yaramayacak bir geri yüklemedir.


Yedekleme hem veri hem de günlük dosyası içerir:

RESTORE FILELISTONLY 
FROM DISK = 'MyDatabase.bak'

Logical Name    PhysicalName
=============   ===============
MyDatabase    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log  C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF

3
Aynı sorunu yaşadım ve tüm çözümler başarısız oldu. İlginç bir şekilde, doğrudan SQL sunucusunda oturum açtım ve DROP DATABASE dbSSMS üzerinden komut verdim ve çalıştı (daha önce komutları vermek için başka bir makineden SSMS kullanıyordum). Diğer çözümlerin de işe yarayacağını tahmin ediyorum.
Salman A

Yanıtlar:


437

Geri yükleme işleminin bir parçası olarak veritabanınızı çevrimiçi duruma getirmek için veritabanı komutunuzla WITH RECOVERYseçeneği kullanmanız gerekir RESTORE.

Bu, elbette, yalnızca herhangi bir işlem günlüğü yedeklemesini geri yüklemeyi amaçlamıyorsanız, yani yalnızca bir veritabanı yedeklemesini geri yüklemek ve sonra veritabanına erişebilmek istiyorsanız.

Komutunuz böyle görünmeli,

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE,RECOVERY

SQL Server Management Studio'daki veritabanı geri yükleme sihirbazını kullanarak daha başarılı olabilirsiniz. Bu şekilde, belirli dosya konumlarını, üzerine yazma seçeneğini ve WITH Recovery seçeneğini belirleyebilirsiniz.


3
Yaptığı işi yaparken kurtarma ifadesini hiç kullanmak zorunda kalmadım. REPLACE İLE yeterli olmalıdır.
Sam

8
Evet, NORECOVERY kullanıyordum ancak geri yükleme işlemi askıda kalıyor. KURTARMA İLE kullanarak, artık işlemi asmak DEĞİŞTİR
Junior Mayhé

Bu benim sorunumu çözdü. Bir geri yüklemenin ortasında bir SAN hatası vardı ve bu hızlı ve temiz bir çözümdü.
Kayıtlı Kullanıcı

Bugün bir SQL Server 2005 veritabanı ile benzer bir sorun yaşadım. Benim durumumda, sorunu çözmek için WITH yan tümcesine ', RESTART' eklemek zorunda kaldım. Önceki işlemin başarılı olmadığını belirten bir hata mesajı veriyordu.
XpiritO

3
@FistOfFury Aynı veritabanında önceki bir geri yükleme işlemi askıya alınmış / uyku durumundaysa, evet. İşlem geri yüklemesinin durdurulması / iptal edilmesi aynı etkiye sahip olmalıdır.
John Sansom

692

Symantec Backup Exec 11d kullanarak bir SQL Server 2005 Standard Edition örneğine bir veritabanı geri yükleme bu durum vardı. Geri yükleme işi tamamlandıktan sonra veritabanı "Geri Yükleniyor" durumunda kaldı. Disk alanı sorunum yoktu - veritabanı "Geri Yükleniyor" durumundan çıkmadı.

SQL Server örneğine karşı aşağıdaki sorguyu çalıştırdım ve veritabanının hemen kullanılabilir hale geldiğini gördüm:

RESTORE DATABASE <database name> WITH RECOVERY

4
Biz 2 saat geri yükleme sıkışmış bir db vardı. Bu komutu ustaya karşı farklı bir makineden çalıştırdık ve bizi düzeltti. Teşekkürler!
Pete

11
+1, bir gotcha ile. Bunu çalıştırdığımda, veritabanının zaten tamamen kurtarıldığını söyleyen bir hata mesajı aldım. Ama yine de "Kurtarmada" durumu olarak gösterildi. Bu yüzden Management Studio'da sağ tıkladım, Refresh'i tıkladım ve normale döndü.
dario_ramos

2
Mng Studio sihirbazını kullanarak geri yükledim, yeni bir veritabanı adı girdim ama yanlışlıkla dosya adlarını mevcut bir veritabanıyla aynı bıraktım. "Geri yükleme başarısız ama günlük kuyruğu başarılı" hatasını aldım ve bu dosyalara ekli veritabanı geri yükleme durumunda kaldı. Bu komut, veritabanını önceki durumuna geri yükledi.
Chris

3
Bu işe yaradı. Yan veritabanına yedeklemeyi geri yüklemeye çalışıyordum, ancak ana veritabanım bir nedenden dolayı geri yükleme durumuna geçti. Bu aslında benim DB kurtardı. Çok teşekkürler!
Aravindh

2
Bazı SSMS geri yükleme sihirbazı varsayılanları, kullanıcı korkusu olmadan çeşitli yedeklemeleri veya günlükleri geri yüklemeye devam edebilmeniz için kaynak DB'yi geri yükleme durumunda bırakır ve bu komut, işiniz bittiğinde DB'yi normale döndürmenin uygun yoludur.
Tim Lehner

102

Bunu nasıl yapacağınız aşağıda açıklanmıştır:

  1. Hizmeti durdurun (MSSQLSERVER);
  2. Veritabanı ve Günlük dosyalarını (C: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...) veya dosyaların bulunduğu her yerde yeniden adlandırın veya silin;
  3. Hizmeti başlatın (MSSQLSERVER);
  4. Sorunlu veritabanını silin;
  5. Veritabanını tekrar geri yükleyin.

Tipu, bunun için teşekkürler. Orijinal postere benzer bir sorunum vardı, ancak geri yüklenirken sunucunun disk alanı tükenmesi ve bu nedenle kalıcı bir geri yükleme durumuna neden oldu.
Pauk

8
Neden sadece veritabanını bırakmıyorsunuz? Bu şekilde hizmeti durdurmak zorunda kalmazsınız.
ErikE

8
@ErikE Benim için SQL sunucusu, geri yüklemenin ortasında bir veritabanını gerçekten geri yüklememesine rağmen bırakamayacağını söyledi ....
Erik Philips

@ErikPhilips Bu durumda birinin servis durdurmaya geri döndüğünü varsayalım. Bunun her seferinde veya sadece sıkışmış geri yükleme sorununun belirli durumlarda olup olmadığını merak ediyorum.
ErikE

5
Benim durumumda, drop database <dbname>bir sorgu penceresinde SQL komutu ile "Geri yükleniyor ..." durumunda asılı olan veritabanı bırakmak yeterliydi . Sonra Veritabanları'na sağ tıkladım ve Management Studio'daki girişi kaldıran Yenile'yi seçtim . Daha sonra yeni bir cezası çalıştığı geri mi ( not getiren çevrimdışı çalışmayı olmadıkları SQL hizmet yeniden başlatma işi yoktu, bir sunucu yeniden başlatma yanı eser yoktu).
Matt

84

Bir günlük nakliye ikincil sunucusunu durdurma ile benzer bir olay yaşadım. Sunucuyu günlük gönderiminden kaldırma ve günlük gönderimini birincil sunucudan durdurma komutundan sonra ikincil sunucudaki veritabanı, komuttan sonra durumu geri yükledi

RESTORE DATABASE <database name> WITH RECOVERY

Veritabanı mesajları:

VERİTABANI GERİ YÜKLE, 18.530 saniyede (0.000 MB / sn) 0 sayfayı başarıyla işledi.

Veritabanı, bu 18 saniye sonra tekrar kullanılabilir.


6
Özellikle veritabanını geri yüklediğinizde ancak KURTARMA seçeneğini unuttuğunuzda kullanışlıdır ...
JBickford

2
Tüm bu veritabanı farklı bir DB adına yedek bir geri yükledikten sonra "Geri yükleme" durumunu bırakmak için gereken tüm oldu. Çok teşekkürler.
Sean

81

SQL Management Studio'yu kullanarak geri yükleme konusunda benzer bir sorun yaşadım. Veritabanının bir yedeğini farklı bir adla yenisine geri yüklemeye çalıştım. İlk başta bu başarısız oldu ve yeni veritabanının dosya adlarını düzelttikten sonra başarıyla gerçekleştirildi - her halükarda, bu hakkını ilk kez alsam bile yeniden tanımlandım. Bu nedenle, restorasyondan sonra orijinal veritabanı adının yanında bir (Geri yükleniyor ...) kaldı. Yukarıdaki forumun cevaplarını göz önüne alarak (Bhusan) aşağıdaki taraftaki sorgu düzenleyicide çalışmayı denedim:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

sorunu çözdü. Özel karakterler içeren veritabanı adı nedeniyle ilk başta sorun yaşıyordum. Ben etrafında çift tırnak ekleyerek bunu çözdüm - tek tırnak "yakınına yakın Sözdizimi ..." hatası vererek işe yaramaz.

Bu, bu sorunu çözmeye çalıştığım minimal çözümdü (geri yükleme durumunda sıkışmış veritabanı) ve umarım daha fazla vakaya uygulanabilir.


2
Mükemmel çalıştı - tekrar ve tekrar yırtmaya gerek kalmadan. 80+ Gb'lik 3 Dbs her biri biraz zaman alır! Teşekkürler!
Christer

1
Neredeyse üretim ortamında yaptım. Önce yerel denedim, aynı durumda sona erdi ve yorumunuzu buldu. Alınan ders: Komut dosyaları kullanın ve önemli durumlarda SSMS'ye güvenmeyin.
Mariusz

1
Bu sorunu, bir veritabanının salt kopya dosya yedeklemesini yeni bir veritabanına geri yüklerken aldım. Özgün veritabanı hatayı gösterdi. Bu çözüm işe yaradı ve aldığım yanıt, "VERİTABANI GERİ YÜKLE 0.263 saniyede (0.000 MB / sn) 0 sayfayı başarıyla işledi" oldu. , SQL Server veritabanının durumu hakkında sadece karışık gibi görünüyor.
R. Schreurs

1
Benim için çalıştı, ancak sadece çift tırnak işaretini kaldırdığımda - parametre olarak [MY_DB_NAME] adlı kullanıcıyı kullandım.
StackOverflowUser

34

Tamam, ben benzer bir sorun var ve tam olarak Pauk olduğu gibi, geri yükleme sırasında disk alanı yetersiz sunucu nedeniyle ve bu nedenle kalıcı geri yükleme durumuna neden oldu. SQL Server hizmetlerini durdurmadan bu durumu nasıl sonlandırabilirim?

Bir çözüm buldum :)

Drop database *dbname*

29

RESTORE DATABASE / RESTORE LOG komutları yürütüldüğünde, RECOVERY WITH varsayılan olarak kullanılır. "Geri yükleme" işleminde sıkışıp kalırsanız, bir veritabanını çalıştırarak çevrimiçi duruma geri getirebilirsiniz:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Birden fazla dosya geri yüklemeye ihtiyaç varsa, CLI komutları sırasıyla NORECOVERY İLE ve KURTARMA İLE gerektirir - veritabanını çevrimiçi duruma getirmek için yalnızca komuttaki son dosya RECOVERY ile olmalıdır:

RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO

SQL Server Management Studio sihirbazını da kullanabilirsiniz:

resim açıklamasını buraya girin

Sanal geri yükleme işlemi de var, ancak 3. taraf çözümlerini kullanmanız gerekecek. Genellikle bir veritabanı yedeklemesini canlı çevrimiçi veritabanı olarak kullanabilirsiniz. ApexSQL ve Idera'nın kendi çözümleri var. SQL Hammer tarafından ApexSQL Geri Yükleme hakkında inceleme . Çok sayıda yedekleme ile uğraşıyorsanız, sanal geri yükleme iyi bir çözümdür. Geri yükleme işlemi çok daha hızlıdır ve disk sürücüsünde çok fazla yer tasarrufu sağlayabilir. Burada biraz karşılaştırma yapmak için infografiklere bakabilirsiniz .


23

Bu oldukça açık olabilir, ama şimdi beni attı:

Kuyruk günlüğü yedeklemesi alıyorsanız, bu soruna SSMS Geri Yükleme sihirbazında - "Kaynak veritabanını geri yükleme durumunda bırak (NORECOVERY İLE)" de neden olabilir.

resim açıklamasını buraya girin


7
Bu durumdaysanız, en iyi seçeneğiniz: 1. Veritabanına sağ tıklayın, Görevler-> Geri Yükle-> İşlem Günlükleri'ne gidin 2. Kuyruk Günlüğü yedeklemesi için kullanılan yedekleme dosyasını bulun. yedekleme Geri yükleme başarılı olmalı ve veritabanını yeniden çevrimiçi duruma getirmelidir.
Ryan Gross

16

Neden olduğunu anladım.

Düzenleyen müşteri RESTORE DATABASEKomutu geri yükleme sırasında bağlantıyı keserse, geri yükleme sıkışacaktır.

İstemci bağlantısıyla bir veritabanını geri yüklemesi söylendiğinde, sunucunun istemci tüm süre boyunca bağlı kalmadıkça geri yüklemeyi bitirmemesi tuhaftır.


10
Tüm SQL Komutları, istemcinin sürekli bağlı kalmasını gerektirir.
mrdenny

2
@mrdenny: Bir istemcinin bağlantısı kesildiğinde değişikliklerin geri alındığını varsayardım.
Ian Boyd

Ben microsoft PHP PDO sürücüsü ile bu komutu çalıştırmada aynı sorun var. Ancak microsoft sql server yönetim stüdyosu ile çalışırken gayet iyi çalışıyor. Nasıl php uygulama tüm zaman bağlı yapmak için acaba?
channa ly

Burada da oldu, DB olası bağlantı kopmasından sonra geri yükleme / tek kullanıcı sıkışmış. Yeni oturumdaki diğer tüm SPID'leri öldürdü, ancak yine de takıldım. Veritabanını çözüm olarak bırakabildi.
crokusek

10

bu işe yaradı:

http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/8dd1b91d-3e14-4486-abe6-e3a550bfe457

Veritabanımın geri yükleme durumunu gösterdiği bir durum vardı ve herhangi bir sorgu çalıştıramadım ve yazılımımıza bağlanamadım.

Bu durumdan kurtulmak için yaptığım şey:

  1. SQL hizmetlerinden SQL ile ilgili tüm hizmetleri durdurun.

  2. Ldf ve Mdf dosyalarının SQL dizininde bulunduğu VERİ klasörünü açtım, normalde şöyle: "C: \ Program Files *********** \ MSSQL \ DATA

  3. Sonra veritabanının hem Ldf hem de Mdf dosyalarını kopyaladım: [db name] .mdf ve [db name] _log.ldf

Bu dosyaların ikisini de başka bir klasöre kopyaladım.

  1. Sonra tüm SQL ile ilgili hizmetleri (adım 1'de) tekrar windows servislerinden başlattım.

  2. MS SQL Management stüdyomu normal girişle başlattım.

  3. Suçlu veritabanını sağ tıklayın ve DELETE tuşuna basın (veritabanını silmek için).

  4. Bu veritabanıyla ilgili tüm LDF ve MDF dosyaları DATA klasöründen (2. adımda belirtilmiştir) geçmiş durumdadır.

  5. Aynı ada sahip yeni bir veritabanı oluşturuldu (6. adımda sildiğim veritabanın adı - suçlu veritabanı).

  6. Sonra [veritabanı adı] -> sağ tıklayın -> görevler -> Çevrimdışı Ol.

  7. Daha sonra her iki dosyayı da (3. adımdan) DATA klasörüne kopyaladım (2. adım).

  8. [veritabanı adı] -> sağ tıklayın -> görevler -> Çevrimiçi Getir.


Bu benim için de işe yaradı. 10. adımda, varolan dosyaların üzerine yazmayı seçtim.
Divi perdomo

8

Sahiptim . benim veritabanı adı, ve sorgu bu nedenle işe yaramadı (yanlış sözdizimi yakın 'diyerek.') Sonra adı için bir parantez gerektiğini fark ettim:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

5

Benim durumumda, "Geri yükleniyor ..." durumunda asılı olan veritabanını SQL komutuyla bırakmak yeterliydi

 drop database <dbname> 

bir sorgu penceresinde.

Sonra Veritabanları'na sağ tıkladım ve Management Studio'daki girişi kaldıran Yenile'yi seçtim . Daha sonra iyi çalışan yeni bir geri yükleme yaptım (çevrimdışı duruma getirmenin işe yaramadığını, SQL hizmetinin yeniden başlatılmasının işe yaramadığını, sunucu yeniden başlatılmasının da işe yaramadığını unutmayın).


3

Ayrıca olay günlüğünde bir TCP hatası aldığımda bu sorun yaşadım ...

Sql ile DB bırakın veya "silme" yöneticisi üzerine sağ tıklayın Ve tekrar geri yükleyin.

Aslında bunu varsayılan olarak yapmaya başladım. DB bırakma komut dosyasını yazın, yeniden oluşturun ve geri yükleyin.


3

Varsayılan olarak, her RESTORE DATABASEbiri RECOVERYkurulumla birlikte gelir . 'NORECOVERY' seçenekleri temel olarak SQL Server'a veritabanının daha fazla geri yükleme dosyası beklediğini söyler ( DIFF dosyası ve LOG olabilir) dosyası olabilir ve mümkünse kuyruk günlüğü yedekleme dosyası içerebilir). 'KURTARMA' seçenekleri, tüm işlemleri bitirir ve veritabanının işlem yapmaya hazır olmasını sağlar.

Yani:

  1. eğer veritabanınız SIMPLE kurtarma modeliyle , DIFF yedeklemeniz olduğunda yalnızca TAM geri yükleme NORECOVERYseçeneğiyle gerçekleştirebilirsiniz . Hayır LOG yedekleme izin verilir BASİT kurtarma modeli veritabanı.
  2. Aksi takdirde, veritabanınız FULL veya BULK-LOGGED kurtarma modeliyle , bir TAM geri yükleme ve ardından NORECOVERYseçeneği gerçekleştirebilir, ardından bir DIFF ve ardından da LOG geri yükleme NORECOVERYgerçekleştirebilirsiniz .RECOVERY

Unutmayın, SON SORGULAMA SORGUSU RECOVERYSEÇENEK OLMALIDIR . Açık bir yol olabilir ya da olmayabilir. T-SQL terminallerinde durum:

1.

 USE [master]
    GO
    RESTORE DATABASE Database_name 
    FROM DISK = N'\\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, 
    RECOVERY -- This option could be omitted.
    GO

REPLACE İLE seçeneği veri kaybına neden olabileceğinden dikkatli kullanılmalıdır

Veya bir TAM ve DIFF yedeklemesi gerçekleştirirseniz, bunu kullanabilirsiniz

   USE [master]
    GO
    RESTORE DATABASE Database_name
      FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
       NOUNLOAD,NORECOVERY
    GO
    RESTORE DATABASE Database_name
      FROM DISK =N'\\path_of_**diff**backup_file.bak' WITH FILE = 1, 
     NOUNLOAD, RECOVERY
    GO

 2. USE [master]
    GO
   -- Perform a Tail-Log backup, if possible. 
   BACKUP LOG Database_name
   GO
   -- Restoring a FULL backup
   RESTORE DATABASE Database_name
    FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
     NOUNLOAD,NORECOVERY
  GO 
  -- Restore the last DIFF backup
  RESTORE DATABASE Database_name
    FROM DISK = N'\\path_of_DIFF_backup_file.bak' WITH FILE = 1,
     NORECOVERY,NOUNLOAD
  GO
  -- Restore a Log backup
  RESTORE LOG Database_name
    FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2,
    RECOVERY, NOUNLOAD
  GO

Elbette , SQL Server'a tamamlanan her% 10'u rapor etmesini bildiren STATS = 10 seçeneğiyle bir geri yükleme gerçekleştirebilirsiniz .

İsterseniz, süreci gözlemleyebilir veya gerçek zamanlı sorguda geri yükleyebilirsiniz. Aşağıdaki gibi:

USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time 
    FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a 
        WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO

Umarım bu yardım.


2

Anlık görüntü etkinleştirilirse, takılan bir veritabanını silme sorunu da olabilir. Benim için bu işe yaradı:

  1. Önce Tipu Delacablu'yu takip ettim adımlarını (birkaç gönderi okuyun)
  2. run command: drop database [veritabanınız], size anlık görüntü veritabanının adını söyleyen bir hata verir
  3. run command: drop database [anlık görüntü veritabanı] 'nı tıklatın ve 2. adımda komutu yeniden çalıştırın.


1

Ben var (geri ...) MyDbName çünkü SQL Express vaka sınırını lisanslı.

Günlük dosyasında şunu buldum:

CREATE DATABASE veya ALTER DATABASE başarısız oldu, çünkü sonuçta elde edilen kümülatif veritabanı boyutu veritabanı başına 10240 MB lisanslı sınırınızı aşacaktır .

Bu nedenle, daha büyük bir veritabanını geri yüklemeye çalışıyorsanız, örneğin SQL Express sunucunuzu Geliştirici sürümüne geçirmeniz gerekir.


TFS veri tabanıydı ve TFS istemcisi bana zaten şunları söyledi: Veritabanı dolu.
cskwg

1

SQL sunucu yönetim stüdyosunu kullanarak veritabanını geri yüklerken benzer bir sorunla karşılaştı ve geri yükleme moduna sıkıştı. Birkaç saatlik sorun izlemeden sonra, aşağıdaki sorgu benim için çalıştı. Aşağıdaki sorgu, veritabanını varolan bir yedekten önceki duruma geri yükler. Bence, catch aynı dizinde .mdf ve .log dosyası olması.

RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY

0
  1. Öncelikle SQL Agent Service'i kontrol edip çalıştırın.
  2. Aşağıdaki T-SQL kullanarak:

    Master.sys.sysalt dosyalarından SELECT dosya adı NEREDE dbid = DB_ID ('db_name');

  3. T-SQL'i sürekli kullanma:

    VERİTABANI DISK'TEN GERİ YÜKLE = 'DB_path' RESTART İLE REPLACE;

Umarım bu yardım!


0

RECOVERY WITH tüm seçenekler benim için çalışmadı.

Yaptığınız şey Management Studio'dan tam geri yükleme yapmaktı.

USE [master]
RESTORE DATABASE Sales_SSD
FROM  DISK = N'D:\databaseBackups02\Daily_Sales_20150309_0941.bak' 
WITH  FILE = 1,  
MOVE N'Sales_Data' TO N'C:\Data\SSD\Sales.mdf',  
MOVE N'Sales_Log' TO N'C:\Data\SSD\Sales_1.ldf',  
NOUNLOAD,  REPLACE,  STATS = 5

0

Ben aynı sorunu vardı ... benim sürücü neden dolu değildi gibi benim veritabanı neden bu sorunu yaşamış bilmiyorum ... Bozuk gibi ya da bir şey gibi. Yukarıdakilerin hepsini denedim, hiçbiri tamamen çalıştı, özellikle hizmeti durdurma önerisini düşündüm ve mdf ve ldf dosyalarını silme işe yarayacaktı ... ama yine de geri yükleme sırasında dondu?

Belirtildiği gibi dosyaları silerek bunu çözdüm, ancak DB'yi geri yüklemeye çalışmak yerine taze .mdf ve .ldf dosyaları üzerine kopyaladım ve Ön Uç Ekleme sihirbazını kullanarak bunları iliştirdim. Rölyef, işe yaradı !!

Sanal Makine kullanıyorum gibi yeni dosyaları kopyalamak için sonsuza dek sürdü ... bu yüzden panoyu kullanarak kopyalama ve yapıştırma bir saat gibi sürdü, bu yüzden sadece son bir girişim olarak tavsiye ederim.


0

Benim için düzelten şey

  1. örneği durdurma
  2. veri klasöründe .mdf ve .ldf dosyalarının yedeğini oluşturma
  3. Örneği yeniden başlatın
  4. geri yüklenen sıkışmış veritabanını sil
  5. .mdf ve.ldf dosyalarını veri klasörüne geri yerleştirin
  6. Örneği .mdf ve .ldf dosyalarına ekleyin

0
RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY

Lütfen bu cevabın daha eski, kabul edilmiş ve son derece yüksek oy alan cevapla karşılaştırıldığında sağladığı ek görüşe dikkat edin. Bu, itibar kazanma umuduyla sadece kopyaladığınız izlenimini önlemeye yardımcı olacaktır. Ayrıca, yalnızca kod yanıtları (ana görünür farktır) burada takdir edilmez, çünkü StackOverflow'un ücretsiz bir kod yazma hizmeti olduğu konusunda yanlış izlenim verirler,
Yunnosch 9:19

Eski cevaba benzerliği daha açık hale getirmek için biçimlendirmeyi düzelttim. Ancak gelecekte bunu daha kolay okunabilir yanıtlar almaya çalışmanız durumunda bunu stackoverflow.com/editing-help adresinden öğrenebilirsiniz .
Yunnosch

0

Bu sorunu çözmek için aşağıdaki komutu kullanın

RESTORE DATABASE [DatabaseName] WITH RECOVERY
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.