セカンダリデータファイルを削除しています。 DBCC SHRINKFILE：作業テーブルページであるため、ページを移動できませんでした
tempdb用に作成したセカンダリデータファイル（.ndf）が多すぎます。余分なファイルを削除するには、ファイルを空にする必要があります（コンテンツは他のファイルに移動されます）。
DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);
次にファイルを削除します。
ALTER DATABASE tempdb REMOVE FILE tempdbfile8;
しかしEMPTYFILEコマンドはエラーを返します：
DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.
心配する必要はありません。このページを使用しているオブジェクトを特定して、それについて何かを行うだけです。
DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920
コマンドは、その中のobject_idのような多くの情報を返します。だが：
Metadata: ObjectId = 0
私はそれについて何をすべきかわかりません。このページの移動を妨げている猫は何ですか？そのオブジェクト、プロセス、セッションなどを見つける方法は？助けていただければ幸いですが、すべてをそのままにするか、代わりに他のファイルを削除することは、この問題に対する有効な解決策ではないことに注意してください;）.
編集：
以前はプロセッサコアごとに1つのファイルを作成する "ベストプラクティス"（同じ初期サイズ、同じ成長率）を使用していたため、ファイルを削除しています。しかし、私の知る限りでは、競合の問題が発生するまで、同じデバイスに追加のtempdbファイルを作成する意味はありません。 [〜＃〜] mpio [〜＃〜] がオンになっていて、ストレージデバイスが4つのパスを処理できるため、この例では理にかなっています。しかし、間違いがあり、6コアのCPUで合計5ファイルになりました。これはMPIOパスよりも多く、CPUコアよりも少なく、偶数ではありません。それは問題を引き起こさないかもしれませんが、ちょうど正しくないようです:)。
データベースを1つ（問題の原因と思われる）をシングルユーザーモード（即時ロールバック）に設定することで、サーバーを再起動せずにファイルを空にして削除することができました。うまくいきましたが、幸運でした。私が本当に望んでいるのは、常にページを追跡できるようにすることです:).
サーバーを再起動するだけで十分です-これらの作業テーブルはクリアされるはずです。しかし、おそらく シングルユーザーモードで起動（-m） して、これらのファイルを正常に削除する前に他のプロセスがワークテーブルを作成しないようにします。次に、tempdbに必要なファイルを再定義します。おそらく、不要なファイルを削除したり、サイズを変更したりします。ファイルの数が偶数であること、すべて同じサイズに設定されていること、およびすべての自動拡張設定（％ではなくMB）があることも確認する必要があります。そして、TF 1117とTF 1118についても検討するのがよいでしょう（ 開始点 ）。
SQL Serverを再起動する前にファイルシステムからファイルを削除するという提案には非常に注意が必要です。まったく起動しない可能性があります。
（ただし、実際の問題が何であるかも知りたいと思います。ファイルが多すぎても問題はありません。）
Mikeがmsdnフォーラムで提案したように、作業テーブルは主にプランキャッシュに関連付けられています。それらをクリアすると、作業テーブルも削除され、Tempdbを縮小できます。これでうまくいきました。これにより、サーバーの再起動も節約できます。 SQLサーバーは実行プランを再作成する必要があるため、オーバーヘッドが発生します。