SQL服務器：堅持「恢復」狀態

Question

在數據庫I備份的數據庫：

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

，然後試圖恢復它：

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

而現在的數據庫被卡在恢復狀態。

有些人推測，這是因爲有備份任何日誌文件，它需要前滾使用：

RESTORE DATABASE MyDatabase 
WITH RECOVERY 

除，當然，失敗：

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. 

正是你想要的災難性情況是無法恢復的。

---

備份包含一個數據和日誌文件：

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 

Answer 1

您需要使用WITH RECOVERY選項，與您的數據庫RESTORE命令，把你的數據庫聯機作爲恢復過程的一部分。

這當然只有在您不打算恢復任何事務日誌備份時，即您只希望恢復數據庫備份，然後才能訪問數據庫。

你的命令應該是這樣的，

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

您可能需要使用SQL Server Management Studio中還原數據庫嚮導更多的成功。這樣您可以選擇特定的文件位置，覆蓋選項和WITH恢復選項。有時候，恢復過程只是因爲數據庫文件的大小而停滯不前。請參閱：https://madhivanan.wordpress.com/2016/09/06/issue-in-recovering-a-database-that-is-in-the-restoring-state-reference/

Answer 2

您是否嘗試過僅運行驗證？只是爲了確保它是一個完善的備份。

http://msdn.microsoft.com/en-us/library/ms188902.aspx

Answer 3

我明白了原因。

如果在還原過程中發出RESTORE DATABASE命令的客戶端斷開連接，還原將會停止。

很奇怪的是，服務器在被告知通過客戶端連接恢復數據庫時，除非客戶端始終保持連接狀態，否則無法完成恢復。

Answer 4

這裏是你如何做到這一點：

1. 停止服務（MSSQLSERVER）;
2. 重命名或刪除數據庫和日誌文件（C：\ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...）或任何你有文件的地方;
3. 啓動服務（MSSQLSERVER）;
4. 刪除有問題的數據庫;
5. 重新恢復數據庫。

祝你好運！

Answer 5

好的，我有類似的問題，正如它在Pauk的情況下一樣，它是由於恢復時服務器磁盤空間不足導致永久恢復狀態。 如何在不停止SQL Server服務的情況下結束此狀態？

我已經找到了解決辦法:)

Drop database *dbname* 

Answer 6

我有這種情況將數據庫還原到使用Symantec的Backup Exec 11d的SQL Server 2005的標準版實例。還原作業完成後，數據庫保持「恢復」狀態。我沒有磁盤空間問題 - 數據庫根本沒有出現「恢復」狀態。

我跑對SQL Server實例下面的查詢，發現該數據庫立即變得可用：

RESTORE DATABASE <database name> WITH RECOVERY 

Answer 7

如果啓用快照還可以有問題刪除卡住數據庫。對於我這樣的工作：

1. 首先，我跟着Tipu Delacablu步驟（讀了幾帖了）
2. 運行命令：DROP DATABASE [數據庫]，它會給你一個錯誤，告訴你的快照數據庫的名稱
3. 運行命令：drop database [snapshot database]，然後再次在步驟2中運行該命令。

Answer 8

我有這個問題時，我也是在事件日誌中收到TCP錯誤...

降數據庫與SQL或經理中右鍵點擊「刪除」 並再次恢復。

我實際上已經開始做這個默認。腳本數據庫刪除，重新創建，然後恢復。

Answer 9

我在停止日誌傳送輔助服務器時發生過類似的事件。 命令後刪除日誌傳送服務器和停止日誌從主服務器傳送輔助服務器上的數據庫陷入了命令後恢復狀態

RESTORE DATABASE <database name> WITH RECOVERY 

的數據庫消息：

RESTORE DATABASE在18.530秒內成功處理0頁 （0.000 MB /秒）。

數據庫在18秒後再次可用。

Answer 10

這個人做的工作：

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

我有一種情況，我的數據庫顯示恢復狀態，我不能運行任何查詢，不能用我們的軟件連接。

我做的事，以擺脫這種情況是：

1. 停止從Windows服務的所有SQL相關的服務。

2. 我打開其中LDF和MDF文件駐留在SQL目錄，通常它像Data文件夾： 「C：\ Program Files文件*********** \ MSSQL \ DATA

3. 然後我複製了數據庫的LDF和MDF文件： [數據庫名稱] .mdf和[數據庫名稱] _log.ldf

我拷貝這兩個文件到另一個文件夾

1. 然後我再次從Windows服務啓動了所有SQL相關服務（在步驟1中）。

2. 以正常登錄啓動我的MS SQL Management Studio。

3. 右鍵單擊罪魁禍首數據庫並點擊DELETE（刪除數據庫）。

4. 與此數據庫相關的所有LDF和MDF文件已從DATA文件夾中刪除（在步驟2中提到）。

5. 創建一個具有相同名稱的新數據庫（與我在步驟6中刪除的名稱相同 - 罪魁禍首數據庫）。

6. 然後[數據庫名稱] - >右鍵單擊 - >任務 - >脫機。

7. 然後我將這兩個文件（從步驟3）複製回DATA文件夾（步驟2）。

8. [數據庫名稱] - >右鍵單擊 - >任務 - >聯機。

Answer 11

1. 讓我們檢查，並首先運行SQL代理服務。

2. 使用下列T-SQL：

   SELECT文件名 FROM master.sys.sysaltfiles WHERE DBID = DB_ID（ 'DB_NAME'）;

3. 使用T-SQL連續：

   RESTORE DATABASE FROM DISK = 'DB_PATH' WITH RESTART，REPLACE;

希望得到這個幫助！

Answer 12

執行RESTORE DATABASE/RESTORE LOG命令時，默認使用WITH RECOVERY選項。如果你停留在「恢復」過程中，你可以通過執行帶回數據庫聯機狀態：

RESTORE DATABASE YourDB WITH RECOVERY 
GO 

如果有需要多個文件恢復，CLI命令需要帶恢復並分別與恢復 - 只有在命令最後的文件應該恢復中帶回數據庫聯機：

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中的嚮導也：

還有虛擬恢復過程，但您必須使用第三方解決方案。通常你可以使用數據庫備份作爲在線數據庫。 ApexSQL和Idera有他們自己的解決方案。 SQL Hammer評論about ApexSQL Restore。如果您正在處理大量備份，虛擬恢復是一個很好的解決方案。還原過程速度更快，也可以節省磁盤驅動器上的大量空間。您可以在這裏查看infographic進行一些比較。

Answer 13

這可能是相當明顯的，但它絆倒了我剛纔：

如果你正在服用尾日誌備份，這個問題也可以通過具有此選項在SSMS檢查還原嚮導造成的 - 「在（WITH NORECOVERY）恢復狀態保留源數據庫」

Answer 14

我不得不使用SQL Management Studio中恢復類似的問題。我嘗試將數據庫的備份恢復到具有不同名稱的新備份。起初，這個失敗了，在修復了新數據庫的文件名後，它成功地執行了 - 無論如何，即使我第一次得到這個權利，我所描述的問題也會再次發生。因此，在恢復之後，原始數據庫的名稱旁邊仍有一個（恢復...）。考慮到上述論壇（Bhusan's）的答案，我嘗試在側面的查詢編輯器中運行以下內容：

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]" 

其中修復了問題。起初我遇到了麻煩，因爲包含特殊字符的數據庫名稱。我通過添加雙引號解決了這個問題 - 單引號不起作用，給出「錯誤的語法接近...」錯誤。

這是我嘗試解決此問題的最小解決方案（數據庫處於恢復狀態），我希望它可以應用於更多案例。

Answer 15

所有基於WITH RECOVERY的選項都不適用於我。

什麼是從Management Studio完成恢復。

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 

Answer 16

我有同樣的問題...雖然我不知道爲什麼我的數據庫遇到此問題作爲我的車是不是全...這就像它被損壞或東西。我嘗試了所有上述都沒有完全工作，我特別認爲建議停止服務和刪除mdf和ldf文件將工作...但它仍然凍結恢復？

我最終通過刪除上述文件來解決這個問題，但不是試圖再次恢復數據庫，而是複製了新的.mdf和。ldf文件並使用前端附件嚮導附加這些文件。救濟，它的工作！

因爲我正在使用虛擬機，所以花了不少時間複製新文件...因此，使用剪貼板複製和粘貼花費了一個小時本身，因此我只會將其推薦爲最後一次嘗試。

Answer 17

我有一個。在我的數據庫名稱，查詢沒有因爲這個工作（說附近有語法錯誤「」），然後我意識到我需要一個支架名稱：

RESTORE DATABASE [My.DB.Name] WITH RECOVERY 

Answer 18

我已經拿到了MyDbName （正在恢復...）由於SQL Express許可限制。

在日誌文件中，我發現這一點：

CREATE DATABASE或ALTER DATABASE 失敗，因爲產生的 累計數據庫的大小將超過10240 MB 每個數據庫的許可上限。

所以，如果你想恢復一個更大的數據庫，你需要在你的SQL Express服務器切換到開發者版例如。

Answer 19

默認情況下，每個RESTORE DATABASE自帶RECOVERY設置。 'NORECOVERY'選項基本上告訴SQL Server數據庫正在等待更多恢復文件（可能是DIFF文件和LOG文件，並且可能包括尾部日誌備份文件）。 'RECOVERY'選項，完成所有事務並讓數據庫準備好執行事務。

所以：

1. 如果你的數據庫設置了SIMPLE恢復模型，你只能執行FULL與NORECOVERY選項還原，當你有一個DIFF備份。否LOG備份允許在SIMPLE恢復模型數據庫。
2. 否則，如果你的數據庫設置了FULL或大容量日誌恢復模式，您可以執行FULL恢復之後NORECOVERY選項，然後執行DIFF其次NORECOVERY，並在最後，執行LOG恢復與RECOVERY選項。

記住，THE LAST還原查詢MUST HAVE RECOVERY OPTION。它可能是一個明確的方式或不是。在T-SQL的情況撒姆：

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

WITH REPLACE選項必須謹慎使用，因爲它會導致數據丟失

或者，如果執行FULL和DIFF備份，則可以使用此

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 

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

當然，你也可以執行與選項恢復STATS = 10，告訴SQL Server的報告，每10％完成。

如果您願意，您可以觀察過程或基於實時查詢恢復。 如下：

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 

希望得到這個幫助。