我希望对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置于打开状态，以查看检查点活动。
是否有人遇到过这种行为，或者知道在事务日志使用率超过70％的情况下，即使日志继续填充，SQL Server是否配置了退避条件来运行检查点？
非常感谢！
答案 0 :(得分：0)
@sepupic指出，发出的70％日志空间使用检查点是自动检查点而非内部检查点的特征（请参阅问题注释）。
出现此行为的简单原因是，在继续执行活动事务时，间接检查点将对脏页阈值违例做出响应。活动事务阻止了检查点发生日志截断，因此事务日志继续增长。
在最后一个间接检查点和先前活动的事务（防止日志截断）完成的时间之间，脏页不足以触发间接检查点的发生。
为什么即使在调查后未发现活动事务，最后一个log_reuse_wait_desc仍保持活动事务，并且通过发出手动CHECKPOINT命令立即清除了日志文件的使用情况。