刪除輔助數據文件。DBCC SHRINKFILE：無法移動頁面，因為它是工作表頁面
我有太多為 .ndf 創建的輔助數據文件 (.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我不知道該怎麼辦。什麼貓阻止了這個頁面被移動？如何定位該對象、程序、會話或其他任何東西？任何幫助將不勝感激，但請注意，將所有內容保持原樣或刪除其他文件並不是解決此問題的有效解決方案；）。
編輯：
我正在刪除這些文件，因為我們曾經遵循“最佳實踐”，即為每個處理器核心創建一個文件（相同的初始大小，相同的增長率）。但據我所知，在您遇到爭用問題之前，沒有必要在同一設備上創建額外的 tempdb 文件。在我們的例子中，這是有道理的，因為我們打開了MPIO ，並且儲存設備可以處理 4 個路徑。但是出現了一個錯誤，我們最終得到了 5 個 6 核 cpu 的文件。它比 MPIO 路徑多，比 CPU 核心少，而且不是偶數。它可能不會引起任何問題，但似乎並不正確:)。
通過將其中一個數據庫（我懷疑導致問題）設置為單使用者模式（立即回滾），我終於能夠在不重新啟動伺服器的情況下清空和刪除文件。它奏效了，但我很幸運。我真正想要的是始終能夠跟踪頁面:)。
重新啟動伺服器就足夠了 - 那些工作表應該被清除。但我可能會以單使用者模式 (-m) 啟動它，以防止其他程序在您成功刪除這些文件之前創建工作表。然後重新定義所需的文件
tempdb；可能會刪除不必要的文件，更改大小等。您還應該確保您擁有偶數個文件，它們都設置為相同的大小，並且它們都具有相同的自動增長設置（以 MB 為單位，而不是 %）。現在可能也是考慮 TF 1117 和 TF 1118 的好時機（起點）。對於在再次啟動 SQL Server 之前從文件系統中刪除文件的建議，我會非常謹慎 - 它可能根本不會啟動。
（不過，我也很好奇實際問題是什麼。文件太多並不會傷害你，真的。）
正如 Mike 在 msdn 論壇中提出的，工作表大多與計劃記憶體相關聯。清除它們也會刪除工作表，然後您可以縮小 Tempdb。這對我有用。這也為您節省了伺服器重新啟動的時間。由於 SQL Server 將不得不再次重新創建執行計劃，因此會有一些成本。