SQL Server sys.databases log_reuse_wait 问题

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_ONLYNO_LOG 选项在当前点断开链。

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


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

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


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

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


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


推荐阅读