SQL Server утечка транзакций

У меня есть база данных, к которой получают доступ около 50 клиентов через TDS через TCP, которая, кажется, не освобождает пространство журнала. Количество процессов остается в пределах ожидаемых 50, а некоторые из них являются довольно долгоживущими (> 120 дней).

База данных теперь имеет 40 ГБ в пространстве журнала (она содержит только 14 ГБ данных), 39 ГБ свободно. Из-за нехватки места на диске, я хотел бы сократить до чего-то более разумного (10 ГБ). Когда я выполняю 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 ЦОД, 16 ГБ памяти, диск для данных и журнала, диск ОС - VHD

в Hyper-V (Windows Server 2008 R2 с пакетом обновления 1 (SP1) x64, центр обработки данных), двухъядерный процессор Intel X5650 (6 ядер, 12 потоков, 2,67 ГГц), 72 ГБ памяти

Гипервизор имеет только три виртуальные машины и не требует большого использования ресурсов. Виртуальная машина SQL Server показывает ~ 40% загрузки процессора и 99% попаданий в кэш.

Существует команда SQL, которая будет показывать ОТКРЫТЫЕ транзакции. (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 здесь .