如何识别和修复简单恢复模型数据库上事务日志增长的原因?

如何识别和修复简单恢复模型数据库上事务日志增长的原因?

我最近将我们的 SQL Server 2008 安装升级到 Service Pack 2。我们的一个数据库处于简单恢复模式,但其事务日志却无休止地增长。日志似乎没有像在简单恢复模式下那样被截断。

我目前正在调查的路径是,我们在某处有一个交易卡在活动状态。原因如下:

select name, recovery_model_desc, log_reuse_wait_desc  from sys.databases where name in ('SimpleDB')
name     recovery_model_desc log_reuse_wait_desc
SimpleDB SIMPLE              ACTIVE_TRANSACTION

当我检查我的活动交易时,我得到了以下信息。请注意,我安装了 SP2 并于 12 月 25 日中午左右重启了我们的服务器。

select transaction_id, name, transaction_begin_time, transaction_type from sys.dm_tran_active_transactions
transaction_id name                         transaction_begin_time   transaction_type
233            worktable                    2010-12-25 12:44:29.283  2
236            worktable                    2010-12-25 12:44:29.283  2
238            worktable                    2010-12-25 12:44:29.283  2
240            worktable                    2010-12-25 12:44:29.283  2
243            worktable                    2010-12-25 12:44:29.283  2
245            worktable                    2010-12-25 12:44:29.283  2
62210          tran_sp_MScreate_peer_tables 2010-12-25 12:45:00.880  1
55422856       user_transaction             2010-12-28 16:41:56.703  1
55422889       SELECT                       2010-12-28 16:41:57.303  2
470            LobStorageProviderSession    2010-12-25 12:44:30.510  2

请注意,根据文档transaction_type 为 1 表示读/写,为 2 表示只读。

因此,我的想法是 trans_sp_MScreate_peer_tables 事务由于某种原因被卡住了,并阻碍了事务日志截断。这是一个合理的场景吗?如果我的想法不对,请纠正我,因为我不是 SQL Server 专家。如果这是正确的,我该如何删除该事务,以便我的事务日志像往常一样被截断?

答案1

运行“DBCC OPENTRAN”,它会告诉你数据库中运行时间最长的 spid。一定要在相关数据库的上下文中运行它。

相关内容