SQL Server泄漏的事务


9

我有一个大约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 dba,但您是否进行了日志备份?serverfault.com/questions/54958/...

@rene,是的,我应该提到这一点,但是数据库每天执行一次完整备份,每六个小时进行一次日志备份。

嗨米奇,可能与这个问题无关,但如果对此负责,也不会感到惊讶。您的版本是RTM(生产发布)。像其他几乎所有软件供应商一样,微软将推动发布具有许多小缺陷的下一个主要版本。[link] microsoft.com/zh-cn/download/details.aspx?id=44271这是指向SQL 2008 R2最新Service Pack的链接。出于安全性,错误修复和性能方面的考虑,最好使您的服务器保持最新。
DamagedGoods 2014年

Answers:



4

无论出于何种原因,似乎都没有任何东西可以打开日志文件。通过运行多个日志备份(> 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

3

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

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

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

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


谢谢您的DBCC LOGINFO命令,我没有意识到这一点。话虽如此,我知道日志的结构,所以不要考虑毫不费力地缩小文件。如前所述,在我们当前的备份结构中,我们仅定期使用约1gb的日志,我想收回一些可用空间。问题是,即使等待了几周,日志末尾的日志空间也没有释放。在此期间,数据库具有许多完整备份和日志备份,这使我相信某些事情会阻止自然循环。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.