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

【问题标题】：SQL Server: Database stuck in "Restoring" stateSQL Server：数据库卡在“正在恢复”状态
【发布时间】：2010-10-05 23:29:00
【问题描述】：

我备份了一个数据库：

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

【问题讨论】：

我遇到了完全相同的问题，所有解决方案都失败了。有趣的是，我直接登录到 SQL 服务器并通过 SSMS 发出DROP DATABASE db 命令并且它工作（之前我使用另一台机器上的 SSMS 来发出命令）。我猜其他解决方案也可以。

标签： sql-server backup restore

【解决方案1】：

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

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

RESTORE DATABASE <database name> WITH RECOVERY

【讨论】：

我们的数据库在恢复过程中停留了 2 小时。我们从另一台机器上针对 master 运行了这个命令，它直接修复了我们。谢谢！
+1，有一个陷阱。运行此程序时，我收到一条错误消息，指出数据库已完全恢复。但它仍然显示为“恢复中”状态。所以我在 Management Studio 中右键单击它，点击 Refresh 并恢复正常。
我使用 Mng Studio 向导进行了恢复，输入了新的数据库名称，但错误地将文件名保留为与现有数据库相同。我收到错误“恢复失败但日志尾成功”，并且附加到这些文件的数据库卡在恢复状态。此命令似乎已将数据库恢复到之前的状态。
这行得通。我试图将备份还原到辅助数据库，但我的主数据库由于某种原因进入了还原状态。这实际上恢复了我的数据库。非常感谢！
一些 SSMS 恢复向导默认设置会使源数据库处于恢复状态，这样您就可以继续恢复各种备份或日志，而不必担心用户，此命令是使数据库恢复正常一次的正确方法你完成了。

【解决方案2】：

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

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

你的命令应该是这样的，

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

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

【讨论】：

在做他正在做的事情时，我从来不需要使用恢复语句。 WITH REPLACE 就足够了。
是的，我正在使用 NORECOVERY，但还原过程挂起。使用 WITH RECOVERY，REPLACE 不再挂起进程
这解决了我的问题。我们在恢复过程中遇到了 SAN 故障，这是一个快速而干净的解决方案。
我今天在使用 SQL Server 2005 数据库时遇到了类似的问题。就我而言，我必须在 WITH 子句中添加 ',RESTART' 来解决问题。它给了我一条错误消息，指出之前的操作不成功。
@FistOfFury 如果同一数据库上的先前还原操作处于挂起/睡眠状态，则可以。简单地停止/取消正在进行的还原应该具有相同的效果。

【解决方案3】：

你是这样做的：

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

【讨论】：

提普，谢谢。我遇到了与原始海报类似的问题，但这是由于服务器在恢复时磁盘空间不足而导致永久恢复状态。
为什么不直接删除数据库？这样您就不必停止服务。
@ErikE 对于我来说，SQL 服务器说它不能在恢复过程中删除数据库，即使它并没有真正恢复......
@ErikPhilips 在那种情况下，我想人们又要停止服务了。我想知道这种情况是每次都发生还是仅在卡住恢复问题的某些情况下发生。
就我而言，在查询窗口中使用 SQL 命令drop database <dbname> 删除处于“正在恢复...”状态的数据库就足够了。然后我右键单击 Databases 并选择 Refresh 删除 Management Studio 中的条目。之后我进行了一次新的恢复，效果很好（注意，让它脱机不起作用，重新启动 SQL 服务不起作用，重新启动服务器也不起作用）。

【解决方案4】：

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

RESTORE DATABASE <database name> WITH RECOVERY

数据库消息：

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

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

【讨论】：

当您已经恢复数据库但忘记了 RECOVERY 选项时特别有用...
在将此数据库的备份恢复到不同的数据库名称后，这就是让它离开“正在恢复”状态所需的全部内容。非常感谢。

【解决方案5】：

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

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

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

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

【讨论】：

完美运行 - 无需再次拆下。每个 80+ Gb 的 3 个 Dbs 需要一段时间！谢谢！
我几乎在生产环境中完成了。我首先在本地尝试过，最终遇到了同样的情况并找到了您的评论。经验教训：在重要情况下使用脚本并且不要信任 SSMS。
我在将数据库的仅复制文件备份恢复到新数据库时遇到了这个问题。原始数据库显示错误。这个解决方案有效，我得到的响应是“RESTORE DATABASE 在 0.263 秒内成功处理了 0 个页面（0.000 MB/秒）。”，所以 SQL Server 似乎只是对数据库的状态感到困惑.
对我有用，但只有当我删除双引号时——我只是将 [MY_DB_NAME] 作为参数。

【解决方案6】：

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

我找到了解决办法:)

Drop database *dbname*

【讨论】：

【解决方案7】：

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

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

【讨论】：

【解决方案8】：

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

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

【讨论】：

如果您处于这种状态，那么您最好的选择是： 1. 右键单击数据库，进入 Tasks->Restore->Transaction Logs 2. 找到用于尾日志备份 3. 恢复备份恢复应该成功并使数据库重新联机。

【解决方案9】：

我知道为什么了。

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

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

【讨论】：

所有 SQL 命令都要求客户端始终保持连接状态。
@mrdenny：我会假设当客户端断开连接时更改会被撤消。
我在使用 Microsoft 的 PHP PDO 驱动程序运行此命令时遇到了同样的问题。但是，当使用 microsoft sql server management studio 运行时，它工作得很好。我想知道如何让我的 php 应用程序一直连接？
这里也发生过，DB 在可能的连接中断后卡在恢复/单用户中。从新会话中杀死所有其他 SPID，但仍然卡住。能够删除数据库作为解决方案。

【解决方案10】：

这个确实有效：

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 文件： [数据库名称].mdf 和 [数据库名称]_log.ldf

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

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

【讨论】：

这对我也有用。在第 10 步，我选择覆盖现有文件。

【解决方案11】：

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

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

【讨论】：

【解决方案12】：

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

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

【讨论】：

【解决方案13】：

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

 drop database <dbname>

在查询窗口中。

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

【讨论】：

【解决方案14】：

使用以下命令解决此问题

RESTORE DATABASE [DatabaseName] WITH RECOVERY

【讨论】：

【解决方案15】：

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

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

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

【讨论】：

【解决方案16】：

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

所以：

如果您的数据库设置为 SIMPLE 恢复模式，则只有在具有 DIFF 备份。 SIMPLE 恢复模式数据库中不允许 LOG 备份。
否则，如果您的数据库设置为 FULL 或 BULK-LOGGED 恢复模式，您可以执行 FULL 恢复，然后执行 @ 987654324@option，然后执行 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

希望对您有所帮助。

【讨论】：

【解决方案17】：

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

首先我按照Tipu Delacablu 的步骤（阅读一些帖子）
运行命令：drop database [your database]，这将给您一个错误，告诉您快照数据库的名称
运行命令：drop database [snapshot database]，然后再次运行步骤 2 中的命令。

【讨论】：

【解决方案18】：

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

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

【讨论】：

【解决方案19】：

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

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

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

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

【讨论】：

是 TFS 数据库，TFS 客户端已经告诉我：数据库已满。

【解决方案20】：

为我解决的问题是

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

【讨论】：

【解决方案21】：

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

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

【讨论】：

【解决方案22】：

让我们先检查并运行 SQL 代理服务。
使用以下 T-SQL：

选择文件名 FROM master.sys.sysaltfiles WHERE dbid = DB_ID('db_name');
连续使用 T-SQL：

从磁盘恢复数据库 = 'DB_path' 和重启，更换；

希望对您有所帮助！

【讨论】：

【解决方案23】：

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

【讨论】：

【解决方案24】：

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

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

因为我使用的是虚拟机，所以复制新文件需要 FOREVER...所以使用剪贴板复制和粘贴本身需要一个小时，所以我只建议将其作为最后一次尝试。

【讨论】：

【解决方案25】：

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

【讨论】：

请指出与旧的、接受的和高度支持的答案相比，此答案提供的额外见解。这将有助于避免仅仅复制它以希望获得声誉的印象。此外，仅代码的答案（这是主要的可见差异）在这里不受欢迎，因为它们给人的错误印象是 StackOverflow 是免费的代码编写服务，
我修复了格式，只是为了使与旧答案的相似性更加明显。但是你可以在这里stackoverflow.com/editing-help 学习这样做，以防你将来尝试做出更易于阅读的答案。

【解决方案26】：

如果要从备份文件中恢复 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;

【讨论】：

【解决方案27】：

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

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

【讨论】：