SQL Server:数据库卡在“恢复”中状态

我备份了一个数据库:

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
1062047 次浏览
小开
最佳答案

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

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

你的命令应该是这样的，

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

使用SQL Server Management Studio中的恢复数据库向导可能会更成功。通过这种方式，您可以选择特定的文件位置、覆盖选项和WITH恢复选项。

小开

你试过运行验证吗?确保这是声音备份。

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

小开

我知道为什么了。

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

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

小开

你可以这样做:

  1. 停止服务(MSSQLSERVER);
  2. 重命名或删除数据库和日志文件(C:\Program files \Microsoft SQL Server\MSSQL.1\MSSQL\Data…)或任何你有文件的地方;
  3. 启动服务(MSSQLSERVER);
  4. 删除有问题的数据库;
  5. 重新恢复数据库。
小开

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

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

Drop database *dbname*
小开

我使用赛门铁克Backup Exec 11d将数据库恢复到SQL Server 2005标准版实例时遇到了这种情况。恢复作业完成后，数据库仍处于“还原”状态。我没有磁盘空间问题——数据库只是没有从“还原”状态中出来。

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

RESTORE DATABASE <database name> WITH RECOVERY
小开

如果启用了快照，删除被卡住的数据库也会有问题。对我来说，这很有效:

  1. 首先，我遵循提普Delacablu步骤(阅读一些帖子)
  2. 运行命令:drop database [your database]，这将给您一个错误，告诉您快照数据库的名称
  3. 执行命令drop database [snapshot database]，然后再执行步骤2中的命令。
小开

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

用sql删除数据库或在管理器“delete”中右键单击它

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

小开

我有一个类似的事件，停止日志运输辅助服务器。 在命令从日志发送中删除服务器并停止从主服务器发送日志之后，次要服务器上的数据库在

命令后陷入恢复状态 
RESTORE DATABASE <database name> WITH RECOVERY

数据库消息:

RESTORE DATABASE在18.530秒内成功处理0个页面 (0.000 MB / sec)。< / p >

在那18秒之后，数据库又可以使用了。

小开

这个方法奏效了:

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

我有一个情况，我的数据库显示恢复状态，我不能运行任何查询，不能与我们的软件连接。

为了摆脱这种情况，我所做的是:

  1. 停止windows服务中的所有SQL相关服务。

    2. 我打开了数据文件夹，其中Ldf和Mdf文件驻留在SQL目录中，通常是这样的: “C: \程序文件 ***********\ 李该\数据< / p > < / > 然后我复制了数据库的Ldf和Mdf文件: (数据库名称)。MDF和[db name]_log.ldf

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

  1. 然后我再次从windows服务中启动所有与SQL相关的服务(在步骤1中)。

  2. 启动我的MS SQL管理工作室正常登录。

  3. 右键单击罪魁祸首数据库并点击DELETE(删除数据库)。

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

  5. 创建一个同名的新数据库(与我在第6步中删除的数据库同名——罪魁祸首数据库)。

  6. 然后[数据库名称]->右键单击->任务->离线。

  7. 然后我将这两个文件(从步骤3)复制回DATA文件夹(步骤2)。

  8. [数据库名称]->右键单击->任务->上线。

小开
  1. 先检查并运行SQL代理服务。

  2. 使用以下T-SQL:

    < p >选择文件名 从master.sys.sysaltfiles WHERE dbid = DB_ID('db_name');

  3. 连续使用T-SQL:

    从磁盘中恢复数据库= 'DB_path' 与 重启,取代;< / p > < /李>

希望这对你有所帮助!

小开

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

enter image description here

也有虚拟恢复过程，但你必须使用第三方解决方案。通常，您可以使用数据库备份作为实时在线数据库。ApexSQL和Idera都有自己的解决方案。回顾SQL Hammer 关于ApexSQL恢复。如果要处理大量备份，虚拟恢复是一个很好的解决方案。恢复过程要快得多，还可以节省磁盘驱动器上的大量空间。您可以在这里查看信息图表进行一些比较。

小开

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

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

enter image description here

小开

我在使用SQL Management Studio进行恢复时遇到了类似的问题。我试图用不同的名称将数据库的备份恢复到新的备份。起初，这个失败了，在修复了新数据库的文件名后，它成功地执行了-在任何情况下，我所描述的问题再次发生，即使我从第一次得到了这个权利。因此，在恢复之后，原始数据库的名称旁边保留了一个(Restoring…)。考虑到上面论坛的答案(Bhusan的)，我试着在旁边的查询编辑器中运行以下:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

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

这是我尝试解决这个问题(数据库处于恢复状态)的最小解决方案，我希望它可以应用到更多的情况。

小开

所有基于WITH RECOVERY的选项都不适合我。

所做的是做完整的恢复从管理工作室。

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文件将工作…但在恢复时仍然死机?

我最终通过删除上面提到的文件来解决这个问题，但我没有尝试再次恢复DB，而是复制了新鲜的.mdf和.ldf文件，并使用前端附件向导附加这些文件。如释重负，它起作用了!!

它花了永远复制的新文件，因为我正在使用虚拟机…所以用剪贴板复制粘贴本身就花了一个小时，所以我只推荐这是最后一次尝试。

小开

我有一个。在我的数据库名称中，查询没有工作，因为(在'.'附近说不正确的语法)然后我意识到我需要一个括号的名称:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY
小开

我已经得到了< em > MyDbName(恢复…)< / em >情况，因为SQL Express许可限制。

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

CREATE DATABASE or ALTER DATABASE 失败了,因为 累积数据库大小为超过您的许可限制10240 MB 每个数据库。< / p >

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

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

所以:

  1. 如果您的数据库设置为简单的恢复模型，那么当您有DIFF备份时，您只能使用NORECOVERY选项执行完整的恢复。在简单的恢复模型数据库中不允许有日志备份。
  2. 否则，如果您的数据库设置为完整的或BULK-LOGGED恢复模型，您可以执行完整的恢复，然后执行DIFF恢复，然后执行NORECOVERY恢复，最后执行日志恢复，使用RECOVERY选项恢复。

记住,# EYZ1。这可能是一种明确的方式，也可能不是。在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

当然，您可以使用统计= 10选项执行恢复，该选项告诉SQL Server每完成10%报告一次。

如果你愿意，你可以在实时查询中观察过程或恢复。 : < / p > 

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

希望这对你有所帮助。

小开

在我的例子中，使用SQL命令挂在“恢复……“状态下的删除数据库就足够了

 drop database <dbname>

在查询窗口中。

然后我右键单击数据库并选择刷新，它删除了SQL Server Management Studio中的条目(地对地导弹)。之后，我做了一个新的恢复，工作良好(注意，使它脱机不起作用，重新启动SQL服务不起作用，服务器重新启动也不起作用)。

小开

为我解决问题的是

  1. 停止实例
  2. 在data文件夹中创建.mdf和.ldf文件的备份
  3. 重新启动实例
  4. 删除恢复卡住的数据库
  5. 把。mdf和。LDF文件返回到数据文件夹
  6. 将实例附加到.mdf和.ldf文件
小开 
RESTORE DATABASE {DatabaseName}
FROM DISK = '{databasename}.bak'
WITH REPLACE, RECOVERY
小开

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

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

请使用以下命令解决此问题

RESTORE DATABASE [DatabaseName] WITH RECOVERY
小开

右键单击数据库转到任务->恢复——比;事务日志 在事务文件中，如果您看到一个文件被选中，则SQL server正在尝试从该文件恢复。 取消选中该文件，并单击OK。数据库恢复.....

这为我解决了问题，希望这能帮助到别人。

小开

如果您想从备份文件恢复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上为我工作。

小开

在我的情况下，我只是右键单击数据库，然后Task-->Restore-->Database-->Ok，一切都变得很好。


提交答案