我备份了一个数据库:

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

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

其他回答

我也有同样的问题……虽然我不知道为什么我的数据库遇到这个问题,因为我的驱动器没有满…好像是被损坏了什么的。我尝试了以上所有的,没有一个完全工作,我特别认为建议停止服务和删除mdf和ldf文件将工作…但在恢复时仍然死机?

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

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

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正在尝试从该文件恢复。 取消选中该文件,并单击OK。数据库恢复.....

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

我今天在虚拟机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后面的存储非常慢,或者有故障。

这个方法奏效了:

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

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

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

停止windows服务中的所有SQL相关服务。 我打开了数据文件夹,其中Ldf和Mdf文件驻留在SQL目录中,通常是这样的: “C: \程序文件 ***********\ 该软件\数据 然后我复制了数据库的Ldf和Mdf文件: (数据库名称)。MDF和[db name]_log.ldf

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

Then I started all the SQL related services (in step 1) again from windows services. Started my MS SQL Management studio with normal login. Right click on the culprit database and hit DELETE (to delete the database at all). All the LDF and MDF files related to this database have gone from DATA folder (mentioned in step 2). Created a new database with the same name (same name of the one I deleted in step 6 - the culprit database). Then [database name]->right click -> tasks -> Take Offline. I then Copied both the files (from step 3) back to the DATA folder (step 2). [database name]->right click -> tasks -> Bring Online.