数据库恢复时间过长的可能原因

Question

这是在 SSC 交叉发布的，但现在恢复需要 6 个小时。

你好，

一夜之间，我使用 NORECOVERY 对 5tb 数据库以及其他几个 250GB - 1.3tb 数据库进行了恢复。我这样做是因为有时我们的 3rd 方备份软件会在认为某些内容超时而实际上没有超时时抛出古怪的 LSN 错误。无论如何，恢复完成没有错误。今天早上，我开始运行 RESTORE WITH RECOVERY 命令，使它们联机以进行 DBCC 检查。

在第一个数据库上运行良好，在 5tb 数据库上卡住了大约一个小时，然后我在其余六个数据库上与 5tb 并行运行命令。他们都恢复得很快。5tb 的数据库现在已经恢复了大约 3 个小时。

任何想法：

为什么这会比两者都花费更长的时间：

a) 恢复通常需要多长时间，以及 b) 比其他数据库恢复所需的时间长得多？

如果我应该取消/终止交易并尝试重新开始

我可以看到它在 sp_WhoIsActive 中做了一些事情，即信息列正在增加，等待信息发生变化（尽管它似乎总是处于等待状态是 IO_COMPLETION），但状态似乎总是被挂起。

在研究时，我发现一篇文章表明高 VLF 计数可能导致此问题，并且日志文件中大约有 5k VLF，但我使用的是 2012 版本，已针对该问题进行了修补：

Microsoft SQL Server 2012 - 11.0.5532.0 (X64) 2014 年 7 月 14 日 15:00:27 版权所有 (c) Microsoft Corporation Developer Edition（64 位）在 Windows NT 6.3（Build 9600：）（Hypervisor）上

谢谢

编辑：

这是在我用于卸载 DBCC 检查的 DBA 机器上，所以我使用了一个很好的备份。这些数据库的增长设置由第 3 方供应商发布的最佳实践控制。我不允许碰它们。它们设置为百分比，我不同意，但这是我无法控制的。管理层不会改变，因为我们按托管空间向客户收费。我每月对 VLF 进行维护，但它们之前一直如此之高，而且我已经毫无问题地运行了恢复。

编辑2：

21小时后完成！

RESTORE DATABASE successfully processed 0 pages in 77454.736 seconds (0.000 MB/sec).

Answer 1

如果这是一个生产环境，绝对不要取消恢复。这只会延长你的痛苦。不要重新启动 SQL 服务器。

1. 等待恢复完成，无论需要多长时间。
2. 确保您有一个良好的备份。
3. 减少虚拟日志文件数量过多的数据库的数量。
4. 将数据库的自动增长设置为一个合理的数字，而不是 10MB 或 10%！例如，如果您的日志文件当前为 50GB 或更大，您可能需要考虑 4GB 或 8GB 的​​增长大小。
5. 使用此脚本或其某些变体来监视数据库上的 VLF 计数，并主动管理它们，以便将来不会遇到此问题。

这个答案有很多关于 VLF 性能的要点。

Kimberly Tripp 有一篇关于如何获得更好的事务吞吐量的优秀文章。

MSDN 有一篇关于从高 VLF 计数缓慢恢复数据库的博客文章。本文针对 SAP 用户，但该信息同样适用于所有 SQL Server 安装。

Linchi Shea 在sqlblog.com 上有一些优点

如果这是一些非生产环境，那么所有的赌注都没有了。您可以随心所欲地杀死那个傻瓜，以找出原因/解决方案。