我备份了一个数据库:

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 Server上遇到了这个问题。我试图恢复一个1.8GB的数据库,它被ASYNC_IO_COMPLETION卡在0%。

我尝试了多次,将.bak文件移动到我要恢复到的驱动器;甚至试图恢复另一个大小<400MB的不相关数据库。

我在这个帖子上尝试了所有的方法,都没有成功。

然后我遇到了恢复卡在DBA的ASYNC_IO_COMPLETION和答案为我工作。

启用“立即文件初始化”并重新启动SQL Server,然后重试恢复。SSMS GUI几乎立即显示进度百分比,如下所示:

Select percent_complete,* From sys.dm_exec_requests

我的猜测是VM后面的存储非常慢,或者有故障。

其他回答

I had a similar issue with restoring using SQL Management Studio. I tried to restore a backup of the database to a new one with a different name. At first this failed and after fixing the new database's file names it was successfully performed - in any case the issue I'm describing re-occurred even if I got this right from the first time. So, after the restoration, the original database remained with a (Restoring...) next to its name. Considering the answers of the forum above (Bhusan's) I tried running in the query editor on the side the following:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

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

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

我今天在虚拟机SQL Server上遇到了这个问题。我试图恢复一个1.8GB的数据库,它被ASYNC_IO_COMPLETION卡在0%。

我尝试了多次,将.bak文件移动到我要恢复到的驱动器;甚至试图恢复另一个大小<400MB的不相关数据库。

我在这个帖子上尝试了所有的方法,都没有成功。

然后我遇到了恢复卡在DBA的ASYNC_IO_COMPLETION和答案为我工作。

启用“立即文件初始化”并重新启动SQL Server,然后重试恢复。SSMS GUI几乎立即显示进度百分比,如下所示:

Select percent_complete,* From sys.dm_exec_requests

我的猜测是VM后面的存储非常慢,或者有故障。

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

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

你的命令应该是这样的,

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

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

我知道为什么了。

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

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

执行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恢复。如果要处理大量备份,虚拟恢复是一个很好的解决方案。恢复过程要快得多,还可以节省磁盘驱动器上的大量空间。你可以看看这里的信息图进行一些比较。