注:この投稿も役に立つかもしれません:
TempDB mdfファイルの問題が増加し続ける
どのプロセスがその作業テーブルを使用しているのか(そしてそれを安全に強制終了できる)を理解できない場合を除き、検索で既に得られた結果に同意する必要があります。サーバーを循環させると、tempdbを圧縮できるはずです。
別の質問では、これを#tempテーブルについて理解することが扱われています。それが作業テーブルに適応できるかどうかはわかりません:
どのセッションがどの一時テーブルを保持しているかを見つける
私はそれについてもブログに書きました(ここでも、#tempテーブル用):
http://sqlperformance.com/2014/05/t-sql-queries/dude-who-owns-that-temp-table
作業テーブルがスナップショット分離/バージョンストアに関連しているとは思いませんが、念のため:
バージョンストアを埋めているトランザクションを見つける
また、依存しないでください。アクティブなトランザクションがあることがわかっていても、そこに表示されないというDBCC OPENTRAN;
多くのシナリオを観察しました。また、データベースコンテキストは重要です。トランザクションがアクティブなデータベースは必ずしもtempdbではありません。ここには何が見えますか?何か?
SELECT * FROM sys.dm_tran_active_transactions
WHERE name = N'worktable';
tempdbを縮小したら
もちろん、これは恒久的な解決策ではありません。tempdbを縮小すると、再び大きくなります。これは、毎回このゲームをプレイするのが非常に退屈で退屈な作業になる可能性があります。そして、それが再び成長するなら、その間にその空きスペースをどうするつもりですか?tempdbが再び必要になったときに、それをリースして、人々を立ち退かせますか?次のいずれかを行う必要があります。
- 最初にtempdbを異常に大きくしているプロセスを修正します。
- tempdbに十分なスペースを割り当てて、拡張する必要がないようにし、圧縮を停止します(特に一時的な場合のみ。これは無駄な作業です)。
他のいくつかの提案:
SHRINKDATABASE
(自動フラグメントと呼ばれる必要があります)またはUIを使用しないでください。特定の対象を絞ったSHRINKFILE
コマンドを記述して、個々のファイルに影響を与えます。
- tempdbに複数のファイルを使用することを検討し(可能であれば別のストレージに分散させることができます)、トレースフラグ1117(この動作がユーザーデータベースにも影響しない限り)と1118 を検討してください。
- ここでtempdbの使用率を最小限に抑えるためのヒント: