当我发现只有在sys.databases" log_reuse_wait"列设置为0的情况下，事务日志才能够正确地截断，这意味着SQL Server 2005事务日志的增长迅速。

有一天，当我打算备份/截断日志文件时，我发现此列在tempdb中出现了4或者ACTIVE_TRANSACTION。然后，我使用DBCC OPENTRAN('tempdb')和sysprocesses中的open_tran列检查是否有未完成的事务。结果是我找不到系统中任何地方的活动事务。

log_reuse_wait列中的设置是否准确？使用上述方法无法检测到正在进行的交易吗？我只是想念一些明显的东西吗？

解决方案

嗯，很棘手。可能是它本身对sys.databases的问题引起了ACTIVE_TRANSACTION？但是，在这种情况下，它应该位于MASTER中，而不是TEMPDB中。

该视频的"参考"链接上有几个指向其他工具/参考的链接，我们可以使用这些工具/参考来帮助解决此问题：
管理SQL Server 2005和2008日志文件

也就是说，log_reuse_wait中的信息应该是准确的。我们可能只是陷入了停滞或者孤立的交易，而无法以某种方式发现它。

我从数据库日志文件中获得的答案已满：

一旦对数据库进行了完整备份，并且数据库没有使用简单恢复模型，SQL Server就会保留对数据库上曾经执行的所有事务的完整记录。这样做是为了在发生灾难性故障时丢失数据文件，可以通过备份日志将故障恢复到故障点，一旦恢复了旧的数据备份，就可以恢复日志以重放丢失的数据交易。

为了防止这种情况的累积，我们必须备份事务日志。或者，我们可以使用BACKUP LOG的TRUNCATE_ONLY或者NO_LOG选项在当前位置断开链接。

如果不需要此功能，请将恢复模型设置为"简单"。

数据可能是准确的。我们需要做的是定期进行事务日志备份。与其他建议相反，我们不应在2005上使用NO_TRUNCATE选项，因为它会清除已提交事务的日志，但不会备份它们。

我们应该做的是通过使用带有NO_TRUNCATE选项的BACKUP LOG语句执行尾日志备份。我们也应该全天使用常规交易日志。这应该有助于使大小保持相当可控。

我仍然不知道为什么没有事务运行时，为什么在sys.databases log_reuse_wait_desc列中看到ACTIVE_TRANSACTION，但是我的后续经验表明，由于不清楚的原因，tempdb的log_reuse_wait列已更改目的，不是很相关。另外，我发现在查找事务信息时，运行DBCC OPENTRAN或者"从sysprocess中选择open_tran"代码比使用以下语句少提供很多信息：

select * from sys.dm_tran_active_transactions

select * from sys.dm_tran_session_transactions 

select * from sys.dm_tran_locks