我备份了一个数据库：

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

---

#1楼

好吧，我有类似的问题，就像Pauk的情况一样，它是由服务器在恢复时耗尽磁盘空间引起的，因此导致永久恢复状态。 如何在不停止SQL Server服务的情况下结束此状态？

我找到了一个解决方案:)

Drop database *dbname*

---

#2楼

我有这种情况使用Symantec Backup Exec 11d将数据库还原到SQL Server 2005 Standard Edition实例。 还原作业完成后，数据库仍处于“正在恢复”状态。 我没有磁盘空间问题 - 数据库根本没有出现“恢复”状态。

我针对SQL Server实例运行了以下查询，发现数据库立即可用：

RESTORE DATABASE <database name> WITH RECOVERY

---

#3楼

这个确实奏效了：

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文件：[db name] .mdf和[db name] _log.ldf

我将这两个文件复制到另一个文件夹。

4. 然后我再次从Windows服务启动了所有SQL相关服务（在步骤1中）。

5. 通过正常登录启动我的MS SQL Management工作室。

6. 右键单击罪魁祸首数据库并点击DELETE（完全删除数据库）。

7. 与此数据库相关的所有LDF和MDF文件都已从DATA文件夹（在步骤2中提到）中删除。

8. 创建了一个具有相同名称的新数据库（与我在步骤6中删除的名称相同 - 罪魁祸首数据库）。

9. 然后[数据库名称] - >右键单击 - >任务 - >脱机。

10. 然后我将两个文件（从步骤3）复制回DATA文件夹（步骤2）。

11. [数据库名称] - >右键单击 - >任务 - >联机。

---

#4楼

如果启用了快照，则删除卡住的数据库也可能存在问题。 对我来说，这工作：

1. 首先我跟随Tipu Delacablu步骤（阅读几篇文章）
2. run命令：drop database [your database]，它会告诉你快照数据库的名称
3. run命令：drop database [snapshot database]，然后再次在步骤2中运行该命令。

---

#5楼

1. 首先检查并运行SQL Agent Service。

2. 使用以下T-SQL：

   SELECT filename FROM master.sys.sysaltfiles WHERE dbid = DB_ID（'db_name'）;

3. 连续使用T-SQL：

   从DISK ='DB_path'恢复数据库WITH RESTART，REPLACE;

希望这有帮助！

---

#6楼

执行RESTORE DATABASE / RESTORE LOG命令时，默认情况下使用WITH RECOVERY选项。 如果您陷入“恢复”过程，则可以通过执行以下操作将数据库恢复为联机状态：

RESTORE DATABASE YourDB WITH RECOVERY
GO

如果需要多个文件恢复，CLI命令分别需要WITH NORECOVERY和WITH RECOVERY - 只有命令中的最后一个文件应具有WITH RECOVERY才能使数据库联机：

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 对ApexSQL Restore的评论 。 如果您处理大量备份，虚拟还原是很好的解决方案。 恢复过程要快得多，也可以节省磁盘驱动器上的大量空间。 您可以在这里查看信息图以进行比较。

---

#7楼

当我在事件日志中收到TCP错误时，我遇到了这个问题...

使用sql删除数据库或在管理器“删除”中右键单击它并再次恢复。

我实际上默认开始这样做了。 编写数据库删除脚本，重新创建然后还原。

---

#8楼

这可能是相当明显的，但它刚刚让我感到沮丧：

如果您正在进行尾部日志备份，则在SSMS还原向导中选中此选项会导致此问题 - “将源数据库保留在还原状态（WITH NORECOVERY）”

---

#9楼

我在使用SQL Management Studio进行恢复时遇到了类似的问题。 我尝试将数据库的备份还原到具有不同名称的新备份。 起初这个失败了，在修复了新数据库的文件名后，它成功地执行了 - 无论如何，即使我从第一次开始这样做，我所描述的问题也重新出现了。 因此，在恢复之后，原始数据库保留在其名称旁边的（恢复...）。 考虑到上面论坛的答案（Bhusan's），我尝试在下面的查询编辑器中运行：

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

这解决了这个问题。 我起初遇到麻烦，因为数据库名称包含特殊字符。 我通过添加双引号来解决这个问题 - 单引号不会产生“错误的语法接近...”错误。

这是我尝试解决此问题的最小解决方案（将数据库置于恢复状态），我希望它可以应用于更多情况。

---

#10楼

所有基于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

---

#11楼

我有同样的问题...虽然我不知道为什么我的数据库遇到了这个问题，因为我的驱动器没有满载......就像它被损坏或者其他东西。 我尝试了以上所有这些都没有完全奏效，我特别认为停止服务和删除mdf和ldf文件的建议会起作用......但它仍然在恢复时冻结了？

我最后通过删除上面提到的文件解决了这个问题，但是我没有尝试再次恢复数据库，而是复制了新的.mdf和.ldf文件并使用前端附件向导附加了这些文件。 救济，它的工作!!

当我使用虚拟机时，FOREVER需要复制新文件...所以使用剪贴板复制和粘贴花了一个小时本身，所以我只推荐这作为最后一次尝试。

---

#12楼

我曾有一个 。 在我的数据库名称中，并且查询因此而无法工作（在'。'附近说错误的语法）然后我意识到我需要一个名称的括号：

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

---

#13楼

由于SQL Express许可限制，我收到了MyDbName（Restoring ...）案例。

在日志文件中，我发现了这个：

CREATE DATABASE或ALTER DATABASE 失败，因为生成的累积数据库大小将超过每个数据库10240 MB的许可限制 。

因此，如果您尝试还原更大的数据库，则需要将SQL Express服务器切换为Developer Edition 。

---

#14楼

默认情况下，每个RESTORE DATABASE都配有RECOVERY设置。 'NORECOVERY'选项，基本上告诉SQL Server数据库正在等待更多的恢复文件（可能是DIFF文件和LOG文件，如果可能的话，可能包括尾日志备份文件）。 'RECOVERY'选项，完成所有事务并让数据库准备好执行事务。

所以：

1. 如果您的数据库设置了SIMPLE恢复模型，则只有在进行DIFF备份时，才能使用NORECOVERY选项执行完全恢复。 SIMPLE恢复模型数据库中不允许LOG备份。
2. 否则，如果您的数据库设置了FULL或BULK-LOGGED恢复模型，则可以执行完全恢复，然后执行NORECOVERY选项，然后执行DIFF ，然后执行NORECOVERY ，最后使用RECOVERY选项执行LOG恢复。

请记住， 最后的恢复查询必须有RECOVERY选项 。 它可能是一种明确的方式。 在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

 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

当然，您可以使用选项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

希望这有帮助。

---

#15楼

我有一个类似的事件，停止日志传送辅助服务器。 命令从日志传送中删除服务器并停止从主服务器发送日志后，辅助服务器上的数据库在命令后陷入恢复状态

RESTORE DATABASE <database name> WITH RECOVERY

数据库消息：

RESTORE DATABASE在18.530秒（0.000 MB /秒）内成功处理了0页。

在那18秒之后，数据库再次可用。

---

#16楼

在我的情况下，使用SQL命令删除处于“正在恢复...”状态的数据库就足够了

 drop database <dbname> 

在查询窗口中。

然后我右键单击Databases并选择Refresh ，删除Management Studio中的条目。 之后我做了一个新的恢复工作正常（请注意，使其脱机不起作用，重新启动SQL服务不起作用，服务器重启也不起作用）。

---

#17楼

您需要使用WITH RECOVERY选项和数据库RESTORE命令将数据库作为还原过程的一部分联机。

这当然只有在您不打算恢复任何事务日志备份时，即您只希望还原数据库备份然后才能访问数据库。

你的命令应该是这样的，

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

您可以使用SQL Server Management Studio中的还原数据库向导进行更多操作。 这样，您可以选择特定文件位置，覆盖选项和WITH Recovery选项。

---

#18楼

你试过运行验证吗？ 只是为了确保它是一个完美的备份。

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

---

#19楼

为我修好的是

1. 停止实例
2. 在数据文件夹中创建.mdf和.ldf文件的备份
3. 重启实例
4. 删除数据库卡住恢复
5. 将.mdf和.ldf文件放回数据文件夹
6. 将实例附加到.mdf和.ldf文件

---

#20楼

我弄明白了为什么。

如果在还原过程中发出RESTORE DATABASE命令的客户端断开连接，则还原将被停止。

奇怪的是，服务器在被告知通过客户端连接恢复数据库时，将无法完成恢复，除非客户端始终保持连接状态。

---

#21楼

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

---

#22楼

这是你如何做到的：

1. 停止服务（MSSQLSERVER）;
2. 重命名或删除数据库和日志文件（C：\\ Program Files \\ Microsoft SQL Server \\ MSSQL.1 \\ MSSQL \\ Data ...）或您拥有文件的位置;
3. 启动服务（MSSQLSERVER）;
4. 删除有问题的数据库;
5. 再次还原数据库。