页面预期寿命在某些时候非常低？

Question

每天我们都会在特定时间段 (03:00 AM - 04:00 AM) 收到一条警报，表明页面预期寿命太低：

SCOM：警报：SQL DB 2008 引擎页面预期寿命太低

我们已查看在此期间是否正在运行任何内存密集型操作，但未发现任何内容。

我们假设原因是通过 Windows 服务运行的查询导致缓冲区缓存中的页面寿命达到非常低的值（8 - 22 秒）

解决此问题的好方法是什么？

感谢奥萨马·瓦利

Answer 1

几乎肯定会是完整备份或索引。查询不会显示为分配的一堆内存，而是显示为密集的磁盘 IO。如果您正在跟踪这些计数器，请查看。其他一些简单的方法来确认这些是磁盘 IO 的原因：

• 查看代理工作时间表。如果不是 checkdb 或索引，那么应用程序通常也会在深夜进行自己的内部数据库清理（例如删除记录）。
• 当 checkdb 运行时，它将被写入 ERRORLOG，因此运行 sp_readerrorlog 并在 PLE 删除时间查找任何内容。这也很有用，因为像 OpsMgr 这样的一些应用程序会在不使用代理作业的情况下随机运行自己的索引和 checkdb 例程。
• 您还可以运行其他查询来确定最近是否更新了索引或统计信息（您可以在每个数据库中运行它并观察结果）。它们不是 100% 准确的，但如果您看到在 PLE 删除时间更新了大量索引或统计数据，这将是一个指标。

否则只需熬夜并以交互方式运行 sp_WhoIsActive 以查看发生了什么。您还可以将 sp_WhoIsActive 输出输出到表，这意味着您可以安排代理作业在 PLE 放置窗口期间将其运行到表中几次，然后在早上检查输出。

如果结果是 checkdb 或索引这种 PLE 行为是相当正常的，并且不会引起问题，除非您有一个非常高的吞吐量或时间敏感的系统，并且在一大清早就很忙；如果没有人抱怨（并且如果您甚至在跟踪它们，那么那时您不会看到查询超时的增加）那么可能只是烟雾而不是火灾。

如果不是 checkdb 或索引怎么办？您可能会遇到错误的查询编译和特殊参数，突然消耗磁盘 IO 并破坏缓冲区。如果幸运的话，当您运行 sp_WhoIsActive 时它会很明显，但如果您不走运，那么您将尝试使用 DMV 浏览计划缓存以找到它。

这是一件非常困难的事情，而且有很多关于它的书；即使您有脚本，它们通常也不会真正汇总查询计划随时间的变化以及执行时间。您可能会浪费几天和几周的时间来尝试解决它，同时设置扩展事件却发现它们出于某种原因没有捕获计划句柄，或者它是一个光标，而您不知道它真正在做什么。

如果你达到了那个点，那么告诉你的老板你需要一个工具来帮助并购买一个像 SQL Sentry 这样的合适监视器的许可证，以便在像这样的真正棘手的问题中进行部署。这就是我所做的。您还可以使用评估或使用其他类似工具进行深入研究。

无论如何，如果结果证明是误报，令人惊讶的是，这是 OpsMgr 的常见缺点。对于某些任务来说，这可能很棒，但对于 SQL Server，无论他们如何尝试硬塞，它都不是一个合适的选择。我无法将其警报调整到功能上可接受的水平，因此无法评论改进。