SQL Server 2019数据库重启后陷入恢复状态

Question

Server错误地重新启动，当它联机时，数据库以“恢复”模式返回。

从错误检查它说：“数据库'DB1‘(5)的恢复是8%完成(大约27146秒剩余)。第二阶段的3。这是一条信息性的消息。这是不需要用户的行动。

它说，它将在8小时内将这个2tb数据库联机。

任何快速的方法来解决这个问题，因为我们没有在日志文件中打开任何东西，所以即使它们被忽略了，它也没有影响。

我们想尽快把这个数据库联机。

Answer 1

你什么也做不了。您的数据库正在经历崩溃恢复，它需要处理事务日志。我更深入地介绍了这个场景，这里。

如果Server最近没有完成检查点，那么就会发生提交的数据库更改，但是只在内存中进行&在事务日志中，而不是在数据文件中。这些更改需要从日志文件中重新进行，这样更改就不会丢失。这就是你的服务器现在正在做的事情。我在我之前链接到的那篇文章中更详细地描述了这些阶段。

如果您的事务日志不必要地非常大，这可能会导致Server执行检查点的频率降低。太大的日志文件或过多的VLFs都会导致崩溃后更长的恢复时间。

对于计划中的重新启动，可以通过在关闭之前执行手动CHECKPOINT;并允许Server服务优雅地停止来最小化/消除延迟。重新启动服务器而不首先停止服务可能导致强制终止sqlservr.exe进程，导致恢复，就像您在启动时看到的那样。

要让你的数据库恢复在线，就耐心点。不要重新启动，不要试图删除日志文件。耐心点。这个估计的恢复时间是出了名的不正确的，所以希望它早日上线，而不是迟。

Answer 2

在Server 2019上，您将来可以使用加速数据库恢复 (ADR)。

发展成果评估的主要好处是：

• 使用ADR快速和一致的数据库恢复，长时间运行的事务不会影响整个恢复时间，从而启用快速和一致的数据库恢复，而不管系统中活动事务的数量或大小。
• 即时事务回滚与ADR，事务回滚是即时的，无论事务活动的时间或已执行的更新数。
• 在ADR中，事务日志被激进地截断，即使在活动的长时间运行的事务存在的情况下，事务日志也是如此，这使得事务日志不会失控。

在默认情况下，它并不是，但是可以在每个数据库中启用它。

默认情况下，Azure SQL数据库和SQL托管实例中启用ADR，因此无法禁用ADR。