SQL Server：数据库陷入“恢复”状态-白红宇

SQL Server：数据库陷入“恢复”状态

阅读量：2292 次

发布时间：2019-05-09

本文共 7091 字，大约阅读时间需要 23 分钟。

我备份了一个数据库：

DATABASE MyDatabaseTO DISK = 'MyDatabase.bak'WITH INIT --overwrite existing

然后尝试恢复它：

DATABASE MyDatabase   FROM DISK = 'MyDatabase.bak'   WITH REPLACE --force restore over specified database

现在数据库仍处于恢复状态。

有些人认为这是因为备份中没有日志文件，需要使用以下方式前滚：

RESTORE DATABASE MyDatabaseWITH RECOVERY

当然，除此之外，失败：

Msg 4333, Level 16, State 1, Line 1The database cannot be recovered because the log was not restored.Msg 3013, Level 16, State 1, Line 1RESTORE 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.mdfMyDatabase_log  C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF

#1楼

好吧，我有类似的问题，就像Pauk的情况一样，它是由服务器在恢复时耗尽磁盘空间引起的，因此导致永久恢复状态。如何在不停止SQL Server服务的情况下结束此状态？

我找到了一个解决方案:)

Drop database *dbname*

#2楼

我有这种情况使用Symantec Backup Exec 11d将数据库还原到SQL Server 2005 Standard Edition实例。还原作业完成后，数据库仍处于“正在恢复”状态。我没有磁盘空间问题 - 数据库根本没有出现“恢复”状态。

我针对SQL Server实例运行了以下查询，发现数据库立即可用：

RESTORE DATABASE 
   
     WITH RECOVERY

#3楼

这个确实奏效了：

我的情况是我的数据库显示恢复状态，我无法运行任何查询，无法连接我们的软件。

我为摆脱这种情况所做的是：

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

我打开了Ldf和Mdf文件驻留在SQL目录中的DATA文件夹，通常是这样的：“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）。

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

#4楼

如果启用了快照，则删除卡住的数据库也可能存在问题。对我来说，这工作：

首先我跟随步骤（阅读几篇文章）

run命令：drop database [your database]，它会告诉你快照数据库的名称

run命令：drop database [snapshot database]，然后再次在步骤2中运行该命令。

#5楼

首先检查并运行SQL Agent Service。

使用以下T-SQL：
SELECT filename FROM master.sys.sysaltfiles WHERE dbid = DB_ID（'db_name'）;

连续使用T-SQL：
从DISK ='DB_path'恢复数据库WITH RESTART，REPLACE;

希望这有帮助！

#6楼

执行RESTORE DATABASE / RESTORE LOG命令时，默认情况下使用WITH RECOVERY选项。如果您陷入“恢复”过程，则可以通过执行以下操作将数据库恢复为联机状态：

RESTORE DATABASE YourDB WITH RECOVERYGO

如果需要多个文件恢复，CLI命令分别需要WITH NORECOVERY和WITH RECOVERY - 只有命令中的最后一个文件应具有WITH RECOVERY才能使数据库联机：

RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'WITH NORECOVERYGORESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'WITH RECOVERYGO

您还可以使用SQL Server Management Studio向导：

在此输入图像描述

还有虚拟还原过程，但您必须使用第三方解决方案。通常，您可以将数据库备份用作实时在线数据库。 ApexSQL和Idera有自己的解决方案。 SQL Hammer 。如果您处理大量备份，虚拟还原是很好的解决方案。恢复过程要快得多，也可以节省磁盘驱动器上的大量空间。您可以在这里查看以进行比较。

#7楼

当我在事件日志中收到TCP错误时，我遇到了这个问题...

使用sql删除数据库或在管理器“删除”中右键单击它并再次恢复。

我实际上默认开始这样做了。编写数据库删除脚本，重新创建然后还原。

#8楼

这可能是相当明显的，但它刚刚让我感到沮丧：

如果您正在进行尾部日志备份，则在SSMS还原向导中选中此选项会导致此问题 - “将源数据库保留在还原状态（WITH NORECOVERY）”

在此输入图像描述

#9楼

我在使用SQL Management Studio进行恢复时遇到了类似的问题。我尝试将数据库的备份还原到具有不同名称的新备份。起初这个失败了，在修复了新数据库的文件名后，它成功地执行了 - 无论如何，即使我从第一次开始这样做，我所描述的问题也重新出现了。因此，在恢复之后，原始数据库保留在其名称旁边的（恢复...）。考虑到上面论坛的答案（Bhusan's），我尝试在下面的查询编辑器中运行：

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

这解决了这个问题。我起初遇到麻烦，因为数据库名称包含特殊字符。我通过添加双引号来解决这个问题 - 单引号不会产生“错误的语法接近...”错误。

这是我尝试解决此问题的最小解决方案（将数据库置于恢复状态），我希望它可以应用于更多情况。

#10楼

所有基于WITH RECOVERY的选项都不适用于我。

从Management Studio完成还原的是什么。

USE [master]RESTORE DATABASE Sales_SSDFROM  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

#11楼

我有同样的问题...虽然我不知道为什么我的数据库遇到了这个问题，因为我的驱动器没有满载......就像它被损坏或者其他东西。我尝试了以上所有这些都没有完全奏效，我特别认为停止服务和删除mdf和ldf文件的建议会起作用......但它仍然在恢复时冻结了？

我最后通过删除上面提到的文件解决了这个问题，但是我没有尝试再次恢复数据库，而是复制了新的.mdf和.ldf文件并使用前端附件向导附加了这些文件。救济，它的工作!!

当我使用虚拟机时，FOREVER需要复制新文件...所以使用剪贴板复制和粘贴花了一个小时本身，所以我只推荐这作为最后一次尝试。

#12楼

我曾有一个。在我的数据库名称中，并且查询因此而无法工作（在'。'附近说错误的语法）然后我意识到我需要一个名称的括号：

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

#13楼

由于SQL Express许可限制，我收到了MyDbName（Restoring ...）案例。

在日志文件中，我发现了这个：

CREATE DATABASE或ALTER DATABASE 失败，因为生成的累积数据库大小将超过每个数据库10240 MB的许可限制 。

因此，如果您尝试还原更大的数据库，则需要将SQL Express服务器切换为Developer Edition 。

#14楼

默认情况下，每个RESTORE DATABASE都配有RECOVERY设置。 'NORECOVERY'选项，基本上告诉SQL Server数据库正在等待更多的恢复文件（可能是DIFF文件和LOG文件，如果可能的话，可能包括尾日志备份文件）。 'RECOVERY'选项，完成所有事务并让数据库准备好执行事务。

所以：

如果您的数据库设置了SIMPLE恢复模型，则只有在进行DIFF备份时，才能使用NORECOVERY选项执行完全恢复。 SIMPLE恢复模型数据库中不允许LOG备份。

否则，如果您的数据库设置了FULL或BULK-LOGGED恢复模型，则可以执行完全恢复，然后执行NORECOVERY选项，然后执行DIFF ，然后执行NORECOVERY ，最后使用RECOVERY选项执行LOG恢复。

请记住， 最后的恢复查询必须有RECOVERY选项 。它可能是一种明确的方式。在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 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％。

如果您愿意，可以观察流程或基于实时查询进行恢复。如下：

USE[master]GOSELECT 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

希望这有帮助。

#15楼

我有一个类似的事件，停止日志传送辅助服务器。命令从日志传送中删除服务器并停止从主服务器发送日志后，辅助服务器上的数据库在命令后陷入恢复状态

RESTORE DATABASE 
   
     WITH RECOVERY

数据库消息：

RESTORE DATABASE在18.530秒（0.000 MB /秒）内成功处理了0页。

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

#16楼

在我的情况下，使用SQL命令删除处于“正在恢复...”状态的数据库就足够了

drop database

在查询窗口中。

然后我右键单击Databases并选择Refresh ，删除Management Studio中的条目。之后我做了一个新的恢复工作正常（请注意，使其脱机不起作用，重新启动SQL服务不起作用，服务器重启也不起作用）。

#17楼

您需要使用WITH RECOVERY选项和数据库RESTORE命令将数据库作为还原过程的一部分联机。

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

你的命令应该是这样的，

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

您可以使用SQL Server Management Studio中的还原数据库向导进行更多操作。这样，您可以选择特定文件位置，覆盖选项和WITH Recovery选项。

#18楼

你试过运行验证吗？只是为了确保它是一个完美的备份。

#19楼

为我修好的是

停止实例

在数据文件夹中创建.mdf和.ldf文件的备份

重启实例

删除数据库卡住恢复

将.mdf和.ldf文件放回数据文件夹

将实例附加到.mdf和.ldf文件

#20楼

我弄明白了为什么。

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

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

#21楼

RESTORE DATABASE {DatabaseName}   FROM DISK = '{databasename}.bak'   WITH REPLACE, RECOVERY

#22楼

这是你如何做到的：

停止服务（MSSQLSERVER）;

重命名或删除数据库和日志文件（C：\\ Program Files \\ Microsoft SQL Server \\ MSSQL.1 \\ MSSQL \\ Data ...）或您拥有文件的位置;

启动服务（MSSQLSERVER）;

删除有问题的数据库;

再次还原数据库。

转载地址：http://oldnb.baihongyu.com/

你可能感兴趣的文章