当我发现事务日志只会正确截断时，我正在调查 SQL Server 2005 事务日志的快速增长 - 如果 sys.databases "log_reuse_wait" 列设置为 0 - 这意味着没有任何东西可以阻止事务日志重用现有空间.
有一天，当我打算备份/截断日志文件时，我发现该列在 tempdb 中有一个 4 或 ACTIVE_TRANSACTION。然后，我使用 DBCC OPENTRAN('tempdb') 和来自 sysprocesses 的 open_tran 列检查了任何打开的事务。结果是我在系统中的任何地方都找不到活动的交易。
log_reuse_wait 列中的设置是否准确？是否存在使用我上面描述的方法无法检测到的交易？我只是错过了一些明显的东西吗？
我仍然不知道为什么我在 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
这里有 log_reuse_wait_desc 是如何工作的解释：
我们还需要了解 log_reuse_wait_desc 报告机制是如何工作的。它给出了上次尝试日志截断时无法发生日志截断的原因。这可能会令人困惑——例如，如果您看到 ACTIVE_BACKUP_OR_RESTORE 并且您知道没有备份或恢复操作正在运行，这仅表示上次尝试日志截断时有一个正在运行。
因此，在您的情况下，现在没有 ACTIVE TRANSACTION，但这是上次尝试截断日志的时候。
There are a couple of links to additional tools/references you can use to help troubleshoot this problem on the References link for this video:
Managing SQL Server 2005 and 2008 Log Files
That said, the information in log_reuse_wait should be accurate. You likely just had a stalled or orphaned transaction that you weren't somehow able to spot.
我对数据库日志文件的回答是完整的：
一旦您对数据库进行了完整备份，并且数据库未使用简单恢复模型，SQL Server 就会完整记录数据库上曾经执行的所有事务。这样做是为了在您丢失数据文件的灾难性故障事件中，您可以通过备份日志恢复到故障点，并且在恢复旧数据备份后，恢复日志以重播丢失的数据交易。
为防止这种情况累积，您必须备份事务日志。或者，您可以使用BACKUP LOG的TRUNCATE_ONLY或选项在当前点断开链。NO_LOG
如果您不需要此功能，请将恢复模式设置为简单。
数据可能是准确的。您需要做的是定期备份事务日志。与其他建议相反，您不应在 2005 年使用 NO_TRUNCATE 选项，因为它会清除已提交事务的日志，但不会备份它们。
您应该做的是使用带有 NO_TRUNCATE 选项的 BACKUP LOG 语句执行尾日志备份。您还应该全天应用常规事务日志。这应该有助于保持大小相当易于管理。
嗯，棘手。难道是它自己对 sys.databases 的问题导致了 ACTIVE_TRANSACTION？但在这种情况下，它应该在 MASTER 而不是 TEMPDB 中。