TempDBデータファイルがSQL 2008でうまく縮小しない
したがって、これが問題にならないようにTempDBデータとログファイルのサイズを適切に事前設定するのが理想的ですが、悪意のある開発者が勤務時間中に本番サーバーでクレイジーな巨大なクエリを実行し、TempDBデータファイルが爆発することがあります。巨大。
TempDBがドライブ上で文字通り唯一のものである場合、おそらくそのままにしておくことができますが、一部のサーバーでは、すべて同じTempDBドライブを共有する複数のSQLインスタンスがあります。
では、インスタンスを再起動せずにこれらのTempDBデータファイルを縮小するにはどうすればよいですか？
私は通常試します：
DBCC SHRINKFILE (name = 'tempdev', size = 5000)
これはSQL 2000と2005でほぼ一貫して機能しました（実際のtempdbアクティビティが徐々に減っていると想定）。2008年にはnotが非常に頻繁に機能するようです（現在のサーバーでは、4つのデータのうち1つしか機能しませんでした）ファイル、他のファイルは引き続き2〜3倍大きくなります）。
ここには2つの異なる質問があります。
Q：悪意のある開発者が業務時間中に本番サーバーでクレイジーな巨大なクエリを実行し、TempDBデータファイルを巨大化させることがあります。
A：これが発生すると、すべてのTempDBデータファイルがほぼ等しく増加するため、特定のファイルの圧縮について心配する必要はありません。率直に言って、それらを縮小する必要はありません。TempDB用に確保されたドライブ領域がある場合は、これらのファイルをそのまま残してください。なぜ同じ戦いを繰り返し続けるのですか？悪質な開発者が数週間で別のクエリを実行するようになります。そのままにしておいてください。空のドライブ容量に基づいてボーナスを獲得することはできません。
さて、TempDBのデータファイルとログファイルがユーザーデータベースと同じボリューム（または天国では禁止、ブートドライブ）にある場合は、それが本当の根本原因であり、修正する必要があります。別のスピンドルに配置しない場合でも、この正確な問題を軽減するには、TempDBを別の論理ボリュームに配置する必要があります。いっぱいになるといっぱいになりますが、ユーザーデータベース（またはCドライブがいっぱいになった場合はサーバー全体）はオフラインになりません。
Q：（DBCC SHRINKFILE）は2008年にはあまり機能しないようです
これは、SQL Serverが各リリースでTempDBにますます依存する方法の関数です。 TempDBで何かがアクティブになると、そのデータを移動できなくなり、新しいバージョンのSQL ServerはTempDBでより多く機能します。たとえば、Read Committed Snapshot Isolationを有効にすると、それが使用するバージョンストアはTempDBに存在します。 AlwaysOn可用性グループを使用すると、TempDBのユーザーデータベース統計も追跡されます。これは、TempDBの論理ボリュームを確保し、データファイルのサイズを設定して、それを満たしてから離れる理由の1つにすぎません。ここでの作業は完了しているので、これらのファイルを縮小しないでください。