運用環境でTempdbを圧縮するベストプラクティス

SQL Server 2008で一時データベースを縮小するときに使用するベストプラクティスは何ですか？

以下を使用するのは危険ですか？

use tempdb
GO

DBCC FREEPROCCACHE -- clean cache
DBCC DROPCLEANBUFFERS -- clean buffers
DBCC FREESYSTEMCACHE ('ALL') -- clean system cache
DBCC FREESESSIONCACHE -- clean session cache
DBCC SHRINKDATABASE(tempdb, 10); -- shrink tempdb
dbcc shrinkfile ('tempdev') -- shrink db file
dbcc shrinkfile ('templog') -- shrink log file
GO

-- report the new file sizes
SELECT name, size
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO

sql-server shrink tempdb

— Mcol
ソース

ベストプラクティスは、成長の原因を突き止めて対処することです。あなたはそれを縮小した場合、それだけで再び成長しており、それは、時間とIOかかる

— Nick.McDermaid

はい、知っています。しかし、私がしなければならないとき、それが積極的になるのが遅れる原因になります:)これは最良の解決策ですか？

申し訳ありませんが、お手伝いできません。

— Nick.McDermaid 14

Tempdbの通常の使用状況を事前に監視し、それに応じてサイズを設定することをお勧めします。これが、TempdbがそのようなサイズとそのPROD環境に成長した1回限りのケースである場合、毎週のメンテナンス中にSQL Serverサービスを再起動します。その後、Tempdbは構成されたサイズに戻ります。

Tempdbが使用されていない限り、ファイルの圧縮は問題ありません。そうでない場合、既存のトランザクションは、ブロックとデッドロックによりパフォーマンスの観点から影響を受ける可能性があります。

プロシージャキャッシュ、バッファキャッシュなどのクリーニングは、それらが再作成されない限り、データベースのパフォーマンス自体に悪影響を及ぼします。PRODではこれを行いません。

お役に立てば幸いです！

神様の入力をありがとう。tempdbのプロセスをsp_whoで確認するだけで十分ですか？

temp dbが使用されているかどうかを確認する信頼できる方法だとは思いません。これは、誰かがSSMSで直接一時テーブルを直接作成している場合にのみ表示されると思います。ただし、メモリの流出などによるクエリ操作の結果として同じことが行われている場合、sp_who2には表示されません。その質問は、実際には別のスレッドになります。それは別の議論なので作成してください。前の回答が役立った場合は、それを回答としてマークしてください。それは同様の状況で他の人を助けるでしょう。