SQL Server泄漏的事务

我有一个大约50个客户端通过TCP的TDS访问的数据库，该数据库似乎没有释放日志空间。进程的数量保持在预期的50左右，其中一些进程的寿命很长（> 120天）。

现在，数据库的日志空间为40 gb（仅包含14 gb数据），空闲空间为39 gb。由于驱动器上的空间限制，我想缩小到更合理的大小（10gb-ish）。当我执行时DBCC SHRINKFILE('db_log', 10000)，它返回一个错误，表示正在使用日志末尾。

为了释放对日志结尾的访问，我尝试通过以下方式将数据库置于单用户模式：

ALTER DATABASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE db SET MULTI_USER
GO

但脚本返回的消息重复了数百次：

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.

这使我相信，在某个地方，我没有进行某些事务。我不知道有什么过程会故意一次打开这么多交易，因此我认为它们必须随着时间的推移而积累，永远不要关闭。

问题：如何找到有问题的进程或脚本，或者为什么不发布日志？

sys.dm_tran_active_transactions显示了合理的18笔交易，目的可以理解。 sp_who仅显示我知道的过程。

SQL Server版本：

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr  2 2010 15:48:46 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

服务器版本：

Windows Server 2008 R2 x64-数据中心4个vCPU，16GB内存，通过磁盘进行数据和日志传递，OS磁盘为VHD

在Hyper-V（Windows Server 2008 R2 SP1 x64数据中心）上双Intel X5650（6核，2.67GHz上有12个线程）72 GB内存

系统管理程序仅具有三个VM，并且不显示高资源使用率。SQL Server VM显示负载下约40％的CPU和99％的缓存命中率。

有一个SQL命令将显示OPEN事务。（DBCC OPENTRAN）

http://msdn.microsoft.com/en-us/library/ms182792.aspx

显示有关指定数据库中最旧的活动事务以及最旧的分布式和非分布式复制事务的信息。仅当存在活动事务或数据库包含复制信息时才显示结果

无论出于何种原因，似乎都没有任何东西可以打开日志文件。通过运行多个日志备份（> 10），释放了日志的结尾，并且可能会发生收缩。不知道为什么...但是有效。

backup log db to disk = '\\l-backup1\drop\2012-12-23_db_log.bak' with stats = 1
go 15
dbcc shrinkfile('db_log', 10240)
go

如果我正确理解了您的问题，那么您有一个40Gb事务日志，其中有39Gb可用空间？日志是一个循环结构，由较小的虚拟日志文件组成。每次VLF已满时，SQL就会开始使用下一个VLF。（不一定与文件中的VLF顺序相同）。当您收缩日志文件时，它将释放日志末尾的可用空间。如果日志的活动部分位于末尾，则无法释放任何空间，如果位于日志中间的某处，则只能回收部分空间。DBCC LOGINFO将向您显示日志中的所有VLF，并显示一个状态，表明VLF当前包含任何活动日志。我相信状态2是活动的，状态0是不活动的。我确定Google可以根据需要提供更多信息。

如果您的问题只是活动部分当前在末尾，那么最好的选择就是等到它再次滚到开始时再收缩日志。请耐心等待，这可能需要花费大量时间。它将到达那里。
还要记住，如果VLF的任何部分当前处于活动状态，则整个VLF都会保持活动状态。

但是，您应该监视日志文件的大小，如果它意外地再次增大，则需要对原因进行一些调查。您应该避免不必要地缩小日志文件，如果日志文件再次增长会降低性能。

有关VLF的更多信息，请参见此处的 Kimberly Tripps博客文章。