SQL Serverリークトランザクション

ログスペースを解放していないように見えるTDS over TCPを介して約50のクライアントからアクセスされるデータベースがあります。プロセスの数は予想される50前後にとどまり、それらのいくつかは非常に長寿命（> 120日）です。

これで、データベースのログ領域に40 GB（データは14 GBのみ）、39 GBが解放されました。ドライブのスペースの制限により、私はもっと妥当なもの（10GBくらい）に縮小したいと思います。を実行する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、16 GBメモリ、データとログ用のパススルーディスク、OSディスクはVHD

Hyper-V（Windows Server 2008 R2 SP1 x64 Datacenter）デュアルIntel X5650（6コア、2.67 GHzで12スレッド）72 GBメモリ

ハイパーバイザーにはVMが3つしかなく、リソースの使用率は高くありません。SQL Server VMは、負荷がかかっている状態で最大40％のCPUと99％のキャッシュヒットを示しています。

OPENトランザクションを表示する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

私があなたの質問を正しく理解している場合、39Gbが無料の40Gbトランザクションログがありますか？ログは、小さな仮想ログファイルで構成される循環構造です。VLFがいっぱいになるたびに、SQLは次のVLFの使用を開始します。（VLFがファイルにあるのと同じ順序である必要はありません）。ログファイルを圧縮すると、ログの最後から空き領域が解放されます。ログのアクティブな部分が最後にある場合、スペースを解放することはできません。それが途中のどこかにある場合は、スペースの一部しか再利用できません。DBCC LOGINFOは、ログ内のすべてのVLFと、VLFに現在アクティブなログが含まれていることを示すステータスを表示します。ステータス2がアクティブで、0が非アクティブであると思います。必要に応じて、Googleがより多くの情報を提供できると確信しています。

問題がアクティブな部分が現在最後にあるだけである場合、最善の策は、それが再び最初に回転するまで待ってから、ログを縮小することです。これには驚くほど時間がかかる場合があります。そこに着くでしょう。
また、VLFの一部が現在アクティブである場合、VLF全体がアクティブのまま維持されることにも注意してください。

ただし、ログファイルのサイズを監視する必要があります。ログファイルが予期せず再び大きくなった場合は、原因を調査する必要があります。ログファイルが不必要に圧縮されないようにする必要があります。再度大きくなると、パフォーマンスが低下する可能性があります。

VLFの詳細については、こちらのキンバリートリップのブログ投稿をご覧ください。