に対して作成したセカンダリデータファイル（.ndf）が多すぎますtempdb。余分なファイルを削除するには、ファイルを空にする必要があります（コンテンツは他のファイルに移動されます）。
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つ（問題の原因と思われる）をシングルユーザーモード（即時ロールバック）に設定することで、サーバーを再起動せずにファイルを空にして削除することができました。うまくいきましたが、幸運でした。私が本当に欲しいのは、常にページを追跡できるようにすることです:)。
dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])ます。ソリューションについて：機能しますが、インスタンスを停止せずにこれを実行したいのですが。