Витік транзакцій на 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 - Datacenter 4 vCPU, 16 Гб пам’яті, пропуск через диск для даних та журналу, диск ОС - це VHD

на Hyper-V (Центр обробки даних Windows Server 2008 R2 SP1 x64) Подвійний Intel X5650 (6 ядер, 12 потоків при 2,67 ГГц) пам'яті 72 Гб

Hypervisor має лише три VM і не демонструє високого використання ресурсів. SQL Server VM показує ~ 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 тут .