【发布时间】：2019-02-11 12:15:14
【问题描述】：
我希望就 SQL Server 中奇怪的检查点行为的原因获得一些意见。
我有一个采用 SIMPLE 恢复模式的数据库，大小从 10 GB 开始。该数据库位于 SQL Server 2017 实例上，并针对间接检查点进行了配置，其中 target_recovery_time_in_seconds 设置为 60。
我们有在事务日志百分比使用率 (70%) 时触发的警报，这通常是内部 CHECKPOINT 发生时。然后，随着事务日志继续增长，我们继续收到警报，最终记录到 99% 已满，但没有进一步增长。
sys.databases 中的 log_reuse_wait_desc 列显示 ACTIVE TRANSACTION 是上次尝试日志截断失败的原因。我确认没有使用接近所有相关 DMV 运行的活动交易。
发出 CHECKPOINT 手动清除 wait_desc 并截断日志。
我的理论是，数据库在最后一次尝试日志截断时有一个活动事务，无论是在超过 70% 的日志使用率时，还是在达到要刷新到磁盘的目标脏缓冲区之后。在任何一种情况下，此时都有一个活动事务阻止了日志截断。由于最后一个检查点的活动很少，因此由于未达到脏缓冲区阈值而导致没有进一步的检查点尝试，因此即使现在没有活动的事务日志截断也不会发生，直到发出 CHECKPOINT。
我打算打开跟踪标志 3502 以在该事务运行时查看检查点活动。
有没有人遇到过这种行为，或者知道 SQL Server 是否为在事务日志使用率超过 70% 时（即使日志继续填满）配置了运行检查点的回退？
非常感谢！
【问题讨论】：
-
只是一些观察。 1.>>>数据库配置为间接检查点，target_recovery_time_in_seconds 设置为 60
-
target_recovery_time_in_seconds 设置为 60 是 SQL Server 2016 中用于间接检查点的默认值，这正是创建数据库时使用的值。内部检查点仍会出现在 70% 的可用空间以刷新脏页并尝试截断日志但被活动事务满足。我觉得奇怪的是 SQL Server 只会在日志百分比为 70% 的情况下触发一次。因为在这个特定的例子中，事务完成后似乎没有足够的页面被弄脏，导致没有 CHECKPOINT，因此没有日志截断。
-
target_recovery_time_in_seconds 的默认值是 0（表示 60 秒），恢复间隔默认值也是 0（表示 1 分钟），但是它们都设置为 0，如果你不'不要碰他们自动检查点被使用。但是，如果您更改 target_recovery_time_in_seconds，则会使用 indirect 检查点。请参阅TARGET_RECOVERY_TIME 和“恢复间隔”选项的交互：docs.microsoft.com/en-us/sql/database-engine/configure-windows/…
-
使用间接检查点时，它们基于自上次检查点以来产生的脏页数量，当使用自动检查点时，它们根据自上次检查点以来产生的日志记录触发，即不同的
-
自动检查点使用 70% 的阈值，而不是内部使用。内部检查点是 dbcc checkdb/checktable 使用的检查点（创建数据库快照时）、关闭发生时、执行完整/差异备份时
标签： sql sql-server sql-server-2016 sql-server-2017