SQL Server 泄露事务

Question

我有一个由大约 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 内存，数据和日志直通磁盘，操作系统磁盘为 VHD

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

Hypervisor 只有三个虚拟机，并没有表现出高资源使用率。SQL Server VM 显示大约 40% 的 CPU 负载和 99% 的缓存命中。

Answer 1

无论出于何种原因，似乎没有任何东西使日志文件保持打开状态。通过运行多个日志备份（>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