SQL Server sys.databases log_reuse_wait 问题

SQL Server sys.databases log_reuse_wait question

当我发现事务日志只会正确截断时，我正在调查 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"代码比在查找事务信息时使用以下语句提供的信息要少得多：

1
2
3
4
5

select * from sys.dm_tran_active_transactions

select * from sys.dm_tran_session_transactions

select * from sys.dm_tran_locks

这里有 log_reuse_wait_desc 是如何工作的解释：

We also need to understand how the log_reuse_wait_desc reporting mechanism works. It gives the reason why log truncation couldn’t happen the last time log truncation was attempted. This can be confusing – for instance if you see ACTIVE_BACKUP_OR_RESTORE and you know there isn’t a backup or restore operation running, this just means that there was one running the last time log truncation was attempted.

因此，在您的情况下，现在没有 ACTIVE TRANSACTION，但这是上次尝试截断日志的时候。

我对数据库日志文件的回答是完整的：

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

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

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

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

也就是说，log_reuse_wait 中的信息应该是准确的。您可能只是有一个您无法以某种方式发现的停滞或孤立的交易。

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

您应该做的是使用带有 NO_TRUNCATE 选项的 BACKUP LOG 语句来执行尾日志备份。您还应该全天应用常规事务日志。这应该有助于保持大小相当易于管理。

嗯，很棘手。难道是它自己对 sys.databases 的问题导致了 ACTIVE_TRANSACTION？但在这种情况下，它应该在 MASTER 而不是 TEMPDB。