SQL Server: Database stuck in “Restoring” state
我备份了一个数据库:
1 2 3 | BACKUP DATABASE MyDatabase TO DISK = 'MyDatabase.bak' WITH INIT --overwrite existing |
然后尝试恢复它:
1 2 3 | RESTORE DATABASE MyDatabase FROM DISK = 'MyDatabase.bak' WITH REPLACE --force restore over specified database |
现在数据库仍处于恢复状态。
有些人认为这是因为备份中没有日志文件,需要使用以下方式前滚:
1 2 | RESTORE DATABASE MyDatabase WITH RECOVERY |
当然,除此之外,失败:
1 2 3 4 | 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. |
确切地说,在灾难性的情况下你想要的是一种无法恢复的恢复。
备份包含数据和日志文件:
1 2 3 4 5 6 7 | 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 |
我有这种情况使用Symantec Backup Exec 11d将数据库还原到SQL Server 2005 Standard Edition实例。还原作业完成后,数据库仍处于"正在恢复"状态。我没有磁盘空间问题 - 数据库根本没有出现"恢复"状态。
我针对SQL Server实例运行了以下查询,发现数据库立即可用:
1 | RESTORE DATABASE <database name> WITH RECOVERY |
您需要使用
当然,这只是在您不打算恢复任何事务日志备份时,即您只希望还原数据库备份然后才能访问数据库。
你的命令应该是这样的,
1 2 3 | RESTORE DATABASE MyDatabase FROM DISK = 'MyDatabase.bak' WITH REPLACE,RECOVERY |
您可以使用SQL Server Management Studio中的还原数据库向导进行更多操作。这样,您可以选择特定文件位置,覆盖选项和WITH Recovery选项。
这是你如何做到的:
我有一个类似的事件,停止日志传送辅助服务器。
命令从日志传送中删除服务器并停止从主服务器发送日志后,辅助服务器上的数据库在命令后陷入恢复状态
1 | RESTORE DATABASE <database name> WITH RECOVERY |
数据库消息:
RESTORE DATABASE successfully processed 0 pages in 18.530 seconds
(0.000 MB/sec).
在那18秒之后,数据库再次可用。
我在使用SQL Management Studio进行恢复时遇到了类似的问题。我尝试将数据库的备份还原到具有不同名称的新备份。起初这个失败了,在修复了新数据库的文件名后,它成功地执行了 - 无论如何,即使我从第一次开始这样做,我所描述的问题也重新出现了。因此,在恢复之后,原始数据库保留在其名称旁边的(恢复...)。考虑到上面论坛的答案(Bhusan's),我尝试在下面的查询编辑器中运行:
1 | RESTORE DATABASE"[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]" |
这解决了这个问题。我起初遇到麻烦,因为数据库名称包含特殊字符。我通过添加双引号来解决这个问题 - 单引号不会产生"错误的语法接近..."错误。
这是我尝试解决此问题的最小解决方案(将数据库置于恢复状态),我希望它可以应用于更多情况。
好吧,我有类似的问题,就像Pauk的情况一样,它是由服务器在恢复时耗尽磁盘空间引起的,因此导致永久恢复状态。
如何在不停止SQL Server服务的情况下结束此状态?
我找到了一个解决方案:)
1 | Drop database *dbname* |
执行RESTORE DATABASE / RESTORE LOG命令时,默认情况下使用WITH RECOVERY选项。如果您陷入"恢复"过程,则可以通过执行以下操作将数据库恢复为联机状态:
1 2 | RESTORE DATABASE YourDB WITH RECOVERY GO |
如果需要多个文件恢复,CLI命令分别需要WITH NORECOVERY和WITH RECOVERY - 只有命令中的最后一个文件应具有WITH RECOVERY才能使数据库联机:
1 2 3 4 5 6 | 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 Restore的评论。如果您处理大量备份,虚拟还原是很好的解决方案。恢复过程要快得多,也可以节省磁盘驱动器上的大量空间。您可以在这里查看信息图以进行比较。
这可能是相当明显的,但它刚刚让我感到沮丧:
如果您正在进行尾部日志备份,则在SSMS还原向导中选中此选项会导致此问题 -"将源数据库保留在还原状态(WITH NORECOVERY)"
我弄明白了为什么。
如果在还原过程中发出
奇怪的是,服务器在被告知通过客户端连接恢复数据库时,将无法完成恢复,除非客户端始终保持连接状态。
这个确实奏效了:
http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/8dd1b91d-3e14-4486-abe6-e3a550bfe457
我的情况是我的数据库显示恢复状态,我无法运行任何查询,无法连接我们的软件。
我为摆脱这种情况所做的是:
从Windows服务停止所有SQL相关服务。
我打开了DATA文件夹,其中Ldf和Mdf文件驻留在SQL目录中,通常是这样的:
"C: Program Files *********** MSSQL DATA
然后我复制了数据库的Ldf和Mdf文件:
[db name] .mdf和[db name] _log.ldf
我将这两个文件复制到另一个文件夹。
然后我再次从Windows服务启动了所有SQL相关服务(在步骤1中)。
通过正常登录启动我的MS SQL Management工作室。
右键单击罪魁祸首数据库并点击DELETE(完全删除数据库)。
与此数据库相关的所有LDF和MDF文件都已从DATA文件夹(在步骤2中提到)中删除。
创建了一个具有相同名称的新数据库(与我在步骤6中删除的名称相同 - 罪魁祸首数据库)。
然后[数据库名称] - >右键单击 - >任务 - >脱机。
然后我将两个文件(从步骤3)复制回DATA文件夹(步骤2)。
[数据库名称] - >右键单击 - >任务 - >联机。
我曾有一个 。在我的数据库名称中,并且查询因此而无法工作(在'。'附近说错误的语法)然后我意识到我需要一个名称的括号:
1 | RESTORE DATABASE [My.DB.Name] WITH RECOVERY |
在我的情况下,使用SQL命令删除处于"正在恢复..."状态的数据库就足够了
1 | drop database <dbname> |
在查询窗口中。
然后我右键单击Databases并选择Refresh,删除Management Studio中的条目。之后我做了一个新的恢复工作正常(请注意,使其脱机不起作用,重新启动SQL服务不起作用,服务器重启也不起作用)。
当我在事件日志中收到TCP错误时,我遇到了这个问题...
使用sql删除数据库或在管理器"删除"中右键单击它
然后再恢复。
我实际上默认开始这样做了。编写数据库删除脚本,重新创建然后还原。
默认情况下,每个
'NORECOVERY'选项,基本上告诉SQL Server数据库正在等待更多的恢复文件(可能是DIFF文件和LOG文件,如果可能的话,可能包括尾日志备份文件)。
'RECOVERY'选项,完成所有事务并让数据库准备好执行事务。
所以:
请记住,最后的恢复查询必须
1。
1 2 3 4 5 6 | 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备份,则可以使用此选项
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | 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%。
如果您愿意,可以观察流程或基于实时查询进行恢复。
如下:
1 2 3 4 5 6 | 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 |
希望这有帮助。
如果启用了快照,则删除卡住的数据库也可能存在问题。对我来说,这工作:
你试过运行验证吗?只是为了确保它是一个完美的备份。
http://msdn.microsoft.com/en-us/library/ms188902.aspx
1 2 3 | RESTORE DATABASE {DatabaseName} FROM DISK = '{databasename}.bak' WITH REPLACE, RECOVERY |
所有基于WITH RECOVERY的选项都不适用于我。
从Management Studio完成还原的是什么。
1 2 3 4 5 6 7 | 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文件并使用前端附件向导附加了这些文件。救济,它的工作!!
当我使用虚拟机时,FOREVER需要复制新文件...所以使用剪贴板复制和粘贴花了一个小时本身,所以我只推荐这作为最后一次尝试。
由于SQL Express许可限制,我收到了MyDbName(Restoring ...)案例。
在日志文件中,我发现了这个:
CREATE DATABASE or ALTER DATABASE failed because the resulting
cumulative database size would exceed your licensed limit of 10240 MB
per database.
因此,如果您尝试还原更大的数据库,则需要将SQL Express服务器切换为Developer Edition。
为我修好的是
使用以下T-SQL:
SELECT文件名
来自master.sys.sysaltfiles
WHERE dbid = DB_ID('db_name');
连续使用T-SQL:
从DISK ='DB_path'恢复数据库
WITH
重新启动,更换;
希望这有帮助!