我备份了一个数据库:
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
答案 0 :(得分:648)
我遇到过这种情况,使用Symantec Backup Exec 11d将数据库还原到SQL Server 2005 Standard Edition实例。还原作业完成后,数据库仍处于“正在恢复”状态。我没有磁盘空间问题 - 数据库根本没有出现“恢复”状态。
我针对SQL Server实例运行了以下查询,发现数据库立即可用:
RESTORE DATABASE <database name> WITH RECOVERY
答案 1 :(得分:416)
您需要使用WITH RECOVERY
选项和数据库RESTORE
命令将数据库作为还原过程的一部分联机。
这当然只有在您不打算恢复任何事务日志备份时,即您只希望恢复数据库备份然后才能访问数据库。
你的命令应该是这样的,
RESTORE DATABASE MyDatabase
FROM DISK = 'MyDatabase.bak'
WITH REPLACE,RECOVERY
使用SQL Server Management Studio中的还原数据库向导可能有更多成功。这样,您可以选择特定的文件位置,覆盖选项和WITH Recovery选项。
答案 2 :(得分:97)
这是你如何做到的:
答案 3 :(得分:82)
我遇到类似事件,停止了日志传送辅助服务器。 在从日志传送中删除服务器并从主服务器停止日志传送的命令之后,辅助服务器上的数据库在命令后陷入恢复状态
RESTORE DATABASE <database name> WITH RECOVERY
数据库消息:
RESTORE DATABASE在18.530秒内成功处理了0个页面 (0.000 MB /秒)。
数据库在18秒后再次可用。
答案 4 :(得分:72)
我在使用SQL Management Studio进行恢复方面遇到了类似的问题。我尝试将数据库的备份还原到具有不同名称的新备份。起初这个失败了,在修复了新数据库的文件名后,它成功地执行了 - 无论如何,即使我从第一次开始这样做,我所描述的问题也重新出现了。因此,在恢复之后,原始数据库保留在其名称旁边的(恢复...)。考虑到上面论坛的答案(Bhusan's),我试着在查询编辑器中运行以下内容:
RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"
修复了这个问题。我起初遇到麻烦,因为数据库名称包含特殊字符。我通过添加双引号来解决这个问题 - 单引号不会产生“错误的语法接近...”错误。
这是我尝试解决此问题的最小解决方案(数据库处于恢复状态),我希望它可以应用于更多情况。
答案 5 :(得分:34)
好吧,我有类似的问题,就像Pauk的情况一样,它是由服务器在恢复时耗尽磁盘空间引起的,因此导致永久恢复状态。 如何在不停止SQL Server服务的情况下结束此状态?
我找到了一个解决方案:)
Drop database *dbname*
答案 6 :(得分:29)
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 about ApexSQL Restore审核。如果您处理大量备份,虚拟还原是很好的解决方案。恢复过程要快得多,也可以节省磁盘驱动器上的大量空间。您可以在此处查看infographic进行比较。
答案 7 :(得分:23)
这可能是相当明显的,但它刚刚让我绊倒了:
如果要进行尾部日志备份,也可以通过在SSMS还原向导中选中此选项来引起此问题 - &#34;将源数据库保留在恢复状态(WITH NORECOVERY)&#34;
答案 8 :(得分:15)
我弄明白了为什么。
如果在恢复期间发出RESTORE DATABASE
命令的客户端断开连接,则恢复将被卡住。
奇怪的是,服务器在被告知通过客户端连接恢复数据库时,除非客户端始终保持连接,否则无法完成恢复。
答案 9 :(得分:10)
这个确实奏效了:
我的情况是我的数据库显示恢复状态,我无法运行任何查询,无法连接我们的软件。
我为摆脱这种情况所做的是:
停止所有与Windows服务相关的SQL相关服务。
我打开了Ldf和Mdf文件所在的DATA文件夹,在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中删除的名称相同 - 罪魁祸首数据库)。
然后[数据库名称] - &gt;右键单击 - &gt;任务 - &gt;离线。</ p>
然后我将这两个文件(从步骤3)复制回DATA文件夹(步骤2)。
[数据库名称] - &gt;右键单击 - &gt;任务 - &gt;带上网。
答案 10 :(得分:6)
RESTORE DATABASE [My.DB.Name] WITH RECOVERY
答案 11 :(得分:5)
对于我来说,只需使用SQL命令
删除处于挂起状态“正在还原...” 的数据库 drop database <dbname>
在查询窗口中。
然后,我右键单击数据库,然后选择 Refresh (这会删除Management Studio中的条目)。之后,我做了一个新的还原,该还原工作正常(请注意,使它脱机不起作用,SQL服务的重新启动不起作用,服务器的重新启动也不起作用)。
答案 12 :(得分:3)
当我在事件日志中收到TCP错误时,我遇到了这个问题...
使用sql删除数据库或在管理器“删除”中右键单击它 然后再次恢复。
我实际上默认开始这样做了。编写数据库删除脚本,重新创建然后恢复。
答案 13 :(得分:3)
默认情况下,每个RESTORE DATABASE
都会设置RECOVERY
。
'NORECOVERY'选项,基本上告诉SQL Server数据库正在等待更多恢复文件(可能是 DIFF 文件和 LOG 文件,可能包括尾部日志备份文件,如果可能的话)。
'RECOVERY'选项,完成所有事务并让数据库准备好执行事务。
所以:
NORECOVERY
选项执行完整还原DIFF 备份。 SIMPLE 恢复模型数据库中不允许 LOG 备份。 NORECOVERY
,最后使用NORECOVERY
选项执行 LOG 还原。 请记住,最后一次恢复查询必须RECOVERY
选项。它可能是一种明确的方式。在T-SQL中,情况如下:
RECOVERY
必须谨慎使用WITH REPLACE选项,否则会导致数据丢失
或者,如果您执行FULL和DIFF备份,则可以使用此
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
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
当然,您可以使用 STATS = 10 选项执行还原,该选项告诉SQL Server报告每完成10%。
如果您愿意,可以观察流程或基于实时查询进行恢复。 如下:
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
希望得到这个帮助。
答案 14 :(得分:3)
右键单击数据库,转至任务->还原->事务日志 在事务文件中,如果看到已检查文件,则说明SQL Server正在尝试从该文件中还原。 取消选中文件,然后单击“确定”。数据库又回来了...
这为我解决了这个问题,希望对您有所帮助。
答案 15 :(得分:2)
如果启用了快照,则删除卡住的数据库也会出现问题。对我来说这很有效:
答案 16 :(得分:2)
使用以下命令解决此问题
RESTORE DATABASE [DatabaseName] WITH RECOVERY
答案 17 :(得分:1)
您是否尝试过仅运行验证?只是为了确保它是一个合理的备份。
答案 18 :(得分:0)
如果要从备份文件还原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;
答案 19 :(得分:0)
这是一个老问题,SQL Server一直存在,甚至是最新的2019版本!我不知道为什么微软这么长时间就一直忍受这种痛苦,并允许他们的MSSQL引擎继续以这种方式运行。不管怎样,我为那些尝试过带恢复功能的RESTORE DATABASE的人提出了另一种可能的解决方案 选项,但仍然无法正常工作。
登录到服务器本身(我很懒,从桌面运行SSMS并根据需要运行到所有数据库服务器),然后在实际的数据库服务器上启动默认的SSMS程序。接下来转到“恢复”数据库并删除它。做完了问题消失了。如果需要保留它,请复制MDF文件并重命名并将其附加为新数据库。在SQL Server 2008 R2上为我工作。
答案 20 :(得分:0)
在使用SQL Server Management Studio还原数据库时遇到了类似的问题,它陷入了还原模式。经过几个小时的问题跟踪,以下查询对我有用。以下查询将数据库从现有备份还原到以前的状态。我相信,要抓住的是将.mdf和.log文件放在同一目录中。
RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY
答案 21 :(得分:0)
RESTORE DATABASE {DatabaseName}
FROM DISK = '{databasename}.bak'
WITH REPLACE, RECOVERY
答案 22 :(得分:0)
精彩的讨论。最大用户最常犯的错误是使用具有多个备份的恢复选项来还原数据库。这使数据库进入还原状态。
如果要进行时间点恢复,则首先进行“还原NoRecovery
”。使用最后一个备份选项,您需要对Recovery
使用Restore。
阅读reference1和reference2有关备份和还原的信息。
答案 23 :(得分:0)
对我来说固定的是
答案 24 :(得分:0)
由于SQL Express许可限制,我收到了 MyDbName(正在恢复...) 的情况。
在日志文件中,我发现了这个:
创建数据库或更改数据库失败,因为结果 累积数据库大小超过您的许可限制10240 MB 每个数据库。
因此,如果您要恢复更大的数据库,则需要将SQL Express服务器切换为开发人员版。
答案 25 :(得分:0)
我遇到了同样的问题...虽然我不知道为什么我的数据库遇到了这个问题,因为我的驱动器没有满载......就像它被损坏了一样。我尝试了以上所有这些都没有完全奏效,我特别认为停止服务和删除mdf和ldf文件的建议会起作用......但它还是在恢复时冻结了吗?
我最后通过删除上面提到的文件解决了这个问题,但我没有尝试再次恢复数据库,而是复制了新的.mdf和.ldf文件,并使用前端附件向导附加了这些文件。救济,它的工作!!
因为我正在使用虚拟机而需要FOREVER复制新文件...所以使用剪贴板复制和粘贴花了一个小时本身,所以我只推荐这作为最后一次尝试。
答案 26 :(得分:0)
所有基于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
答案 27 :(得分:0)
使用以下T-SQL:
SELECT filename 来自master.sys.sysaltfiles WHERE dbid = DB_ID('db_name');
连续使用T-SQL:
从DISK ='DB_path'恢复数据库 WITH RESTART,REPLACE;
希望这有帮助!