SQL Server：数据库卡在“正在恢复”状态

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

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

RESTORE DATABASE <database name> WITH RECOVERY

---

您需要将 WITH RECOVERY 选项与您的数据库 RESTORE 命令一起使用，以使您的数据库在线作为恢复过程的一部分。

当然，这仅适用于您不打算恢复任何事务日志备份的情况，即您只希望恢复数据库备份然后能够访问数据库。

你的命令应该是这样的，

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

使用 SQL Server Management Studio 中的还原数据库向导可能会获得更多成功。这样，您可以选择特定的文件位置、覆盖选项和 WITH Recovery 选项。

---

这是你如何做到的：

停止服务（MSSQLSERVER）；重命名或删除数据库和日志文件 (C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data...) 或您拥有文件的任何位置；启动服务（MSSQLSERVER）；删除有问题的数据库；再次恢复数据库。

---

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

RESTORE DATABASE <database name> WITH RECOVERY

数据库消息：

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

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

---

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

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

这解决了这个问题。起初我遇到了麻烦，因为数据库名称包含特殊字符。我通过在周围添加双引号解决了这个问题 - 单引号不起作用，给出“...附近的语法不正确”错误。

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

---

好的，我有类似的问题，与 Pauk 的情况完全一样，它是由于服务器在恢复时磁盘空间不足而导致的，因此导致了永久恢复状态。如何在不停止 SQL Server 服务的情况下结束此状态？

我找到了解决方案:)

Drop database *dbname*

---

执行 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 向导：

https://i.stack.imgur.com/fctbj.png

还有虚拟恢复过程，但您必须使用第 3 方解决方案。通常您可以使用数据库备份作为实时在线数据库。 ApexSQL 和 Idera 有自己的解决方案。由 SQL Hammer about ApexSQL Restore 审查。如果您要处理大量备份，虚拟还原是一个很好的解决方案。恢复过程要快得多，也可以节省大量磁盘驱动器空间。您可以在此处查看 infographic 进行一些比较。

---

这可能是相当明显的，但它刚刚绊倒了我：

如果您正在进行尾日志备份，则此问题也可能是由于在 SSMS 还原向导中选中了此选项 - “使源数据库处于还原状态（WITH NORECOVERY）”

https://i.stack.imgur.com/gWlxG.jpg

---

右键单击数据库转到任务 --> 恢复 --> 事务日志 在事务文件中，如果您看到一个文件被选中，那么 SQL Server 正在尝试从该文件恢复。取消选中该文件，然后单击“确定”。数据库回来了……

这为我解决了这个问题，希望这对某人有所帮助。

---

我想通了为什么。

如果发出 RESTORE DATABASE 命令的客户端在恢复过程中断开连接，则恢复将卡住。

奇怪的是，当客户端连接告诉服务器恢复数据库时，除非客户端始终保持连接，否则服务器不会完成恢复。

---

这个确实有效：

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

我的数据库显示正在恢复状态，我无法运行任何查询，也无法连接我们的软件。

我为摆脱这种情况所做的是：

从 Windows 服务停止所有 SQL 相关服务。我打开了 Ldf 和 Mdf 文件位于 SQL 目录中的 DATA 文件夹，通常它类似于：“C:\Program Files***********\MSSQL\DATA 然后我复制了 Ldf 和 Mdf数据库文件：[db name].mdf 和 [db name]_log.ldf

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

然后我再次从 Windows 服务启动所有 SQL 相关服务（在步骤 1 中）。以正常登录方式启动了我的 MS SQL 管理工作室。右键单击罪魁祸首数据库并点击 DELETE（完全删除数据库）。与此数据库相关的所有 LDF 和 MDF 文件都已从 DATA 文件夹中删除（在步骤 2 中提到）。创建了一个具有相同名称的新数据库（与我在步骤 6 中删除的数据库相同的名称 - 罪魁祸首数据库）。然后【数据库名称】->右键->任务->脱机。然后我将两个文件（从步骤 3 开始）复制回 DATA 文件夹（步骤 2）。 [数据库名称]->右键单击->任务->联机。

---

我曾有一个 。在我的数据库名称中，因此查询不起作用（在'。'附近说语法不正确）然后我意识到我需要一个括号作为名称：

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

---

使用以下命令解决此问题

RESTORE DATABASE [DatabaseName] WITH RECOVERY

---

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

 drop database <dbname> 

在查询窗口中。

然后我右键单击 Databases 并选择 Refresh，这会删除 SQL Server Management Studio (SSMS) 中的条目。之后我做了一个新的恢复，效果很好（请注意，使它脱机不起作用，重新启动 SQL 服务不起作用，重新启动服务器也不起作用）。

---

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

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

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

---

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

所以：

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

请记住，最后的恢复查询必须有 RECOVERY 选项。这可能是一种明确的方式，也可能不是。在T-SQL的Therms中，情况：

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

希望这有帮助。

---

如果启用快照，删除卡住的数据库也可能会出现问题。对我来说，这很有效：

首先，我按照 Tipu Delacablu 的步骤（阅读几篇文章）运行命令：drop database [your database]，它会给你一个错误，告诉你快照数据库的名称运行命令：drop database [snapshot database]，然后运行再次执行步骤 2 中的命令。

---

您是否尝试过仅运行验证？只是为了确保它是一个健全的备份。

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

---

由于 SQL Express 许可限制，我得到了 MyDbName (Restoring...) 案例。

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

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

因此，如果您尝试恢复更大的数据库，例如，您需要将 SQL Express 服务器切换到 Developer 版本。

---

为我解决的问题是

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

---

使用 SQL Server Management Studio 还原数据库时遇到类似问题，它陷入了还原模式。经过几个小时的问题跟踪，以下查询对我有用。以下查询将数据库从现有备份恢复到以前的状态。我相信，问题在于将 .mdf 和 .log 文件放在同一目录中。

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

---

首先让我们检查并运行 SQL 代理服务。使用以下 T-SQL： SELECT filename FROM master.sys.sysaltfiles WHERE dbid = DB_ID('db_name');连续使用 T-SQL：RESTORE DATABASE FROM DISK = 'DB_path' WITH RESTART, REPLACE;

希望这有帮助！

---

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

---

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

我最终通过删除提到的文件解决了这个问题，但我没有尝试再次恢复数据库，而是复制了新的 .mdf 和 .ldf 文件，并使用前端附件向导附加了这些文件。放心，成功了！！

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

---

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

---

如果要从备份文件恢复 SQL Server 数据库，可以使用以下脚本：

RESTORE DATABASE [MyDatabase] -- which database to restore
FROM DISK = N'X:\MyDatabase.bak' -- location of the database backup
WITH 
    FILE = 1, -- restore from a backup file
    -- declare where the file groups should be located (can be more than two)
    MOVE N'MyDatabase_Data' TO N'D:\SSDPATH\MyDatabase.mdf',
    MOVE N'MyDatabase_Log' TO N'E:\HDDPATH\MyDatabase.ldf',
    -- Tape option; only relevant if you backup from magnetic tape
    NOUNLOAD,
    -- brings the database online after the database got restored
    -- use this option when you don't want to restore incremental backups
    -- use NORECOVERY when you want to restore differential and incremental backup files
    RECOVERY,
    -- replace existing database with the backup 
    -- deletes the existing database
    REPLACE, 
    -- print log message for every 1 percent of restore
    STATS = 1;

---

这是 SQL Server 一直存在的老问题，即使是最新的 2019 版本！我不知道为什么微软让这种痛苦持续了这么久，并允许他们的 MSSQL 引擎继续以这种方式运行。尽管如此，我还是为那些尝试了 RESTORE DATABASE WITH RECOVERY 选项的人提出了另一种可能的解决方案，但它仍然不起作用。

登录到服务器本身并在实际数据库服务器上启动默认的 SSMS 程序。接下来转到“恢复”数据库并删除它。完毕。问题消失了。如果您需要保留它，请复制 MDF 文件并将其重命名并将其作为新数据库附加。在 SQL Server 2008 R2 上为我工作。

---