Question

当我发现事务日志只会正确截断时 - 我正在调查SQL Server 2005事务日志的快速增长 - 如果sys.databases“log_reuse_wait”列设置为0 - 这意味着什么都没有保留事务日志重用现有空间。

有一天，当我打算备份/截断日志文件时，我发现此列在tempdb中有一个4或ACTIVE_TRANSACTION。然后，我使用DBCC OPENTRAN（'tempdb'）和sysprocesses中的open_tran列检查任何打开的事务。结果是我在系统中的任何地方都找不到活动的交易。

log_reuse_wait列中的设置是否准确？是否存在使用上述方法无法检测到的交易？我只是遗漏了一些明显的东西吗？

Answer 1

我仍然不知道为什么我在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

Answer 2

Here有解释log_reuse_wait_desc如何工作：

我们还需要了解log_reuse_wait_desc报告机制的工作原理。它给出了上次尝试日志截断时不能发生日志截断的原因。这可能会让人感到困惑 - 例如，如果您看到ACTIVE_BACKUP_OR_RESTORE并且您知道没有正在运行的备份或还原操作，这只意味着上次尝试进行日志截断时有一个正在运行。

所以在你的情况下，现在没有ACTIVE TRANSACTION，但是上次尝试进行日志截断时。

Answer 3

在此视频的“参考”链接上，您可以使用其他一些指向其他工具/参考的链接来帮助解决此问题：
Managing SQL Server 2005 and 2008 Log Files

也就是说，log_reuse_wait中的信息应该是准确的。您可能只是发生了陷阱或孤立的交易，而您无法以某种方式发现。

Answer 4

来自My answer的

The Log File for Database is Full：

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

要防止此建立，您必须备份事务日志。或者，您可以使用BACKUP LOG的TRUNCATE_ONLY或NO_LOG选项在当前点中断链。

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

Answer 5

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

您应该做的是使用带有NO_TRUNCATE选项的BACKUP LOG语句执行尾部日志备份。您应该在一天中应用常规事务日志。这应该有助于保持大小的可管理性。

Answer 6

嗯，很棘手。它可能是sys.databases自带的问题导致了ACTIVE_TRANSACTION吗？但在这种情况下，它应该在MASTER而不是TEMPDB中。

SQL Server sys.databases log_reuse_wait问题

6 个答案: