SQL服务器:坚持“恢复”状态

问题描述:

在数据库I备份的数据库:SQL服务器:坚持“恢复”状态

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 

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

这当然只有在您不打算恢复任何事务日志备份时,即您只希望恢复数据库备份,然后才能访问数据库。

你的命令应该是这样的,

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

您可能需要使用SQL Server Management Studio中还原数据库向导更多的成功。这样您可以选择特定的文件位置,覆盖选项和WITH恢复选项。有时候,恢复过程只是因为数据库文件的大小而停滞不前。请参阅:https://madhivanan.wordpress.com/2016/09/06/issue-in-recovering-a-database-that-is-in-the-restoring-state-reference/

+2

我从来没有使用恢复声明时,他正在做什么。 WITH REPLACE就足够了。 – Sam 2009-02-06 20:23:50

+6

是的,我正在使用NORECOVERY,但恢复过程挂起。使用WITH RECOVERY,REPLACE不会挂起进程 – 2009-09-16 19:26:06

+0

这解决了我的问题。我们在恢复过程中出现SAN故障,这是一个快速而干净的解决方案。 – 2009-09-21 19:21:30

您是否尝试过仅运行验证?只是为了确保它是一个完善的备份。

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

我明白了原因。

如果在还原过程中发出RESTORE DATABASE命令的客户端断开连接,还原将会停止。

很奇怪的是,服务器在被告知通过客户端连接恢复数据库时,除非客户端始终保持连接状态,否则无法完成恢复。

+10

所有SQL命令都要求客户端始终保持连接状态。 – mrdenny 2009-08-28 07:12:51

+2

@mrdenny:我会假设当客户端断开连接时,更改会被撤消。 – 2009-08-28 14:28:59

这里是你如何做到这一点:

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

祝你好运!

+0

Tipu,谢谢你。我遇到了与原始海报类似的问题,但这是由于服务器在恢复时磁盘空间不足而导致永久恢复状态。 – Pauk 2009-05-22 14:44:16

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

我已经找到了解决办法:)

Drop database *dbname* 

我有这种情况将数据库还原到使用Symantec的Backup Exec 11d的SQL Server 2005的标准版实例。还原作业完成后,数据库保持“恢复”状态。我没有磁盘空间问题 - 数据库根本没有出现“恢复”状态。

我跑对SQL Server实例下面的查询,发现该数据库立即变得可用:

RESTORE DATABASE <database name> WITH RECOVERY 
+3

我们有一个数据库停留在恢复2小时。我们从一台不同的机器上运行这个命令来对抗主机,它将我们固定了起来。谢谢! – Pete 2011-06-14 18:08:43

如果启用快照还可以有问题删除卡住数据库。对于我这样的工作:

  1. 首先,我跟着Tipu Delacablu步骤(读了几帖了)
  2. 运行命令:DROP DATABASE [数据库],它会给你一个错误,告诉你的快照数据库的名称
  3. 运行命令:drop database [snapshot database],然后再次在步骤2中运行该命令。

我有这个问题时,我也是在事件日志中收到TCP错误...

降数据库与SQL或经理中右键点击“删除” 并再次恢复。

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

我在停止日志传送辅助服务器时发生过类似的事件。 命令后删除日志传送服务器和停止日志从主服务器传送辅助服务器上的数据库陷入了命令后恢复状态

RESTORE DATABASE <database name> WITH RECOVERY 

的数据库消息:

RESTORE DATABASE在18.530秒内成功处理0页 (0.000 MB /秒)。

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

+6

当您已经恢复数据库但忘记了RECOVERY选项时尤其有用...... – JBickford 2011-03-18 20:31:13

这个人做的工作:

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

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

我做的事,以摆脱这种情况是:

  1. 停止从Windows服务的所有SQL相关的服务。

  2. 我打开其中LDF和MDF文件驻留在SQL目录,通常它像Data文件夹: “C:\ Program Files文件*********** \ MSSQL \ DATA

  3. 然后我复制了数据库的LDF和MDF文件: [数据库名称] .mdf和[数据库名称] _log.ldf

我拷贝这两个文件到另一个文件夹

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

  2. 以正常登录启动我的MS SQL Management Studio。

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

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

  5. 创建一个具有相同名称的新数据库(与我在步骤6中删除的名称相同 - 罪魁祸首数据库)。

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

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

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

  1. 让我们检查,并首先运行SQL代理服务。
  2. 使用下列T-SQL:

    SELECT文件名 FROM master.sys.sysaltfiles WHERE DBID = DB_ID( 'DB_NAME');

  3. 使用T-SQL连续:

    RESTORE DATABASE FROM DISK = 'DB_PATH' WITH RESTART,REPLACE;

希望得到这个帮助!

执行RESTORE DATABASE/RESTORE LOG命令时,默认使用WITH RECOVERY选项。如果你停留在“恢复”过程中,你可以通过执行带回数据库联机状态:

RESTORE DATABASE YourDB WITH RECOVERY 
GO 

如果有需要多个文件恢复,CLI命令需要带恢复并分别与恢复 - 只有在命令最后的文件应该恢复中带回数据库联机:

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评论about ApexSQL Restore。如果您正在处理大量备份,虚拟恢复是一个很好的解决方案。还原过程速度更快,也可以节省磁盘驱动器上的大量空间。您可以在这里查看infographic进行一些比较。

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

如果你正在服用尾日志备份,这个问题也可以通过具有此选项在SSMS检查还原向导造成的 - “在(WITH NORECOVERY)恢复状态保留源数据库”

enter image description here

我不得不使用SQL Management Studio中恢复类似的问题。我尝试将数据库的备份恢复到具有不同名称的新备份。起初,这个失败了,在修复了新数据库的文件名后,它成功地执行了 - 无论如何,即使我第一次得到这个权利,我所描述的问题也会再次发生。因此,在恢复之后,原始数据库的名称旁边仍有一个(恢复...)。考虑到上述论坛(Bhusan's)的答案,我尝试在侧面的查询编辑器中运行以下内容:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]" 

其中修复了问题。起初我遇到了麻烦,因为包含特殊字符的数据库名称。我通过添加双引号解决了这个问题 - 单引号不起作用,给出“错误的语法接近...”错误。

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

所有基于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 [My.DB.Name] WITH RECOVERY 

我已经拿到了MyDbName (正在恢复...)由于SQL Express许可限制。

在日志文件中,我发现这一点:

CREATE DATABASE或ALTER DATABASE 失败,因为产生的 累计数据库的大小将超过10240 MB 每个数据库的许可上限。

所以,如果你想恢复一个更大的数据库,你需要在你的SQL Express服务器切换到开发者版例如。

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

所以:

  1. 如果你的数据库设置了SIMPLE恢复模型,你只能执行FULLNORECOVERY选项还原,当你有一个DIFF备份。否LOG备份允许在SIMPLE恢复模型数据库。
  2. 否则,如果你的数据库设置了FULL大容量日志恢复模式,您可以执行FULL恢复之后NORECOVERY选项,然后执行DIFF其次NORECOVERY,并在最后,执行LOG恢复与RECOVERY选项。

记住,THE LAST还原查询MUST HAVE RECOVERY OPTION。它可能是一个明确的方式或不是。在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 
  1. 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
  2. 当然,你也可以执行与选项恢复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 
    

    希望得到这个帮助。

开始=>