自安装SP3以来Server 2008事务日志的增长

Question

在我们的产品db (~117 db)上，我们复制了相当多的表。历史上，我们的维护计划一直保持事务日志相当小。自从我们安装了SP3以来，事务日志增长很快(目前为213 we )。

我们通过检查注册表条目来确保安装成功，但不太确定还需要检查什么。搜索没有发现任何类似的问题，SP3是罪魁祸首。

也不太确定如何查看事务日志，因为DBCC日志结果充其量只能是神秘的。

这是版本的输出：

Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64)   
Sep 21 2011 22:45:45   
Copyright (c) 1988-2008 Microsoft Corporation  Standard Edition (64-bit) 
   on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) 

完全恢复模式=每天备份事务日志= true。

这是一个生产数据库，多年来事务日志保持在小规模，没有问题.直到SP3出现。

我运行了DBCC OpenTran并发现如下：

最老的活动事务: SPID (服务器进程ID)：9s UID (用户ID)：-1名称: tran_sp_MScreate_peer_tables LSN：(365893:25399:1)启动时间:2011年11月12日8:26:10:927AM SID : 0x01复制事务信息:最老的分布式LSN：(366831:664081:8)最老的非分布式LSN：(0:0:0)

很多其他人在服务包安装后报告了同样长时间的运行过程.嗯嗯。

不太确定该怎么办。可能会考虑暂停或终止我的复制作业，看看它是否消失了。所有迹象表明，由于它是'9s‘SPID，系统拥有它，它不能被杀死。

关于如何进行的思考？

Answer 1

我建议这两个人是无关的。

有什么变化吗？

• 在维护计划设置中
• 数据库的恢复模型(在简单的地方，它现在已经满了吗)
• 您在维护计划(完整)之前进行了日志备份吗？你还这么做吗？
• 你在维修计划中有自动收缩吗？不管怎么说，这很糟糕
• 是否有任何正在阻止日志备份(或收缩)的打开事务？

另外，从另一台服务器上的预sp3恢复数据库，并比较sys.databases条目。

Answer 2

一个好的开始是查看这个数据库的log_reuse_wait_desc列在sys.databases中。这将告诉您为什么不截断日志。下面的BOL文章将帮助您解释结果：http://msdn.microsoft.com/en-us/library/ms345414.aspx。

Answer 3

听起来您的数据库处于完全恢复模式。你能证实一下吗？

您正在备份事务日志吗？如果它还在生长，我猜不会。检查你的维修计划是否真的在做你想做的事情。有与此相关的SQL代理作业。您可以查看日志备份作业的历史记录，以查看它是否实际成功。我猜它不是，否则您的日志文件将被截断，当您备份它，它不会增长。

此外，备份事务日志的间隔是多少？如果没有足够的时间，它就会长出来。在做得太频繁和太少之间有一种快乐的媒介。