apt*_*605 6 sql-server-2005 transaction-log checkpoint
我们似乎遇到了一个莫名其妙的问题。检查点进程卡在 SLEEP_BPOOL_FLUSH 状态，并没有真正减少日志文件中的使用。
这在以前似乎从未发生过。
我知道 SLEEP_BPOOL_FLUSH 是磁盘子系统繁忙时对 CHECKPOINT 进程的正常等待。实际上，我们一直有一个非常繁忙的磁盘子系统，所以我不明白为什么这会成为一个问题。
（如果您手动运行检查点命令，同样的结果...您的用户进程在 SLEEP_BPOOL_FLUSH 中等待）。
我们可以做些什么来推动检查点发生？是否可以调整检查点的参数以免发生这种情况？
（SQL Server 2005，RAID 子系统，简单恢复模型）
如果资源监视器显示 SQL Server 实际上正在执行检查点（即，它工作正常，只是速度很慢），那么您所能做的就是等待。
如果磁盘子系统仍然很忙（共享存储？），是否有可能其他负载已增加，而现在 I/O 子系统已接近或达到最大容量？如果您没有测量（记录）可以告诉您这一点的指标，我强烈建议您直接使用 PerfMon 或其他一些第三方工具。（这还取决于存储架构。要点是能够跟踪一段时间内的 I/O 负载。）如果您使用 SAN，I/O 子系统本身是否存在透明的变化到你的 SQL 框？
您可以考虑的一件事是更改恢复间隔设置，它允许您手动控制检查点发生的频率。请注意，这是一个实例设置。我强烈建议您在更改之前仔细阅读文档，因为偏离默认值可能会让事情变得更糟（取决于您的工作量）。