FlushCache消息在特定时间出现在日志中

最近，我们一直在遇到许多数据库性能问题，并且我一直在尝试看看是否能找出原因。我们没有DBA（我是软件开发人员），所以我有点像在指点翅膀，而且我在网上找到的许多内容对我来说就像是一门外语。

我们每天早上都重新启动SQL Server，因为这是它在工作日内运行的唯一方式。我注意到每天凌晨5点左右，我们开始每两分钟在日志中收到此消息：

FlushCache：针对DB 9：0用97168 ms的7432次写入清理了11848个buf（避免了8139个新的脏buf）

最后未完成的目标：4，avgWriteLatency 32

平均吞吐量：0.72 MB /秒，I / O饱和度：11635，上下文切换18849

这些数字当然每次都会有所不同，但是在我重新启动服务器之前，该消息一遍又一遍地重复着相同的消息。我不确定如何解释这一点，我一直在尝试向Google寻求它，而我所收集的只是这意味着I / O可能有问题，并且花费的时间比预期的要长。我们最近改用了SSD，因此我认为这应该不是写问题。

有人能对此有所启示吗？

错误日志中的FlushCache消息是由检查点记录引起的，在这种情况下，是由较长的检查点（定义为花费比恢复时间间隔更长的检查点）引起的。无论是否记录，在2012年之前和2012年之前的行为都是不同的。在SQL Server 2012之前，要获取检查点日志记录，您必须打开跟踪标志（T3504）。但是从SQL Server 2012开始，遇到长检查点时，默认情况下会记录该消息。

现在，关于“这真的不好吗？”的问题。，您确实需要开始根据具体情况查看这些数字。仅花费93+秒的时间即可刷新大约93 MB的脏缓冲区。看起来这很可能是大量数据流失的混合物（在实际检查点本身中，还弄脏了约64 MB的缓冲区）和潜在的存储空间，无法满足数据修改和/或其他需求I / O工作负载。

我要做的就是验证您的存储子系统的运行状况，查看等待情况，然后获取实例的整体性能情况。查看逻辑磁盘性能计数器，并查看吞吐量，延迟和IOps的总体I / O变动。它将帮助您更生动地描绘磁盘的性能。如果您有能力对存储进行基准测试（如果尚未对其进行基准测试），则应查看这些卷具有的功能（SQLIO是一个很好的实用程序）以及它们现在正在做什么（很高兴站起来比较当前基准时有基准基准）。

这是一篇很好的文章，解释了此消息- 如何工作：何时将FlushCache消息添加到SQL Server错误日志？

编辑：重新阅读您的问题，我一定错过了此评论：

我注意到每天早上5点左右我们开始收到此消息

根据以上指南，查看此时存储中正在发生的情况。这听起来像教科书计划的操作正在消耗存储空间，导致检查点性能下降并变长。