TempDB 上的 DDL 爭用
我有一個 SQL Server 2005 Standard x64，在過去幾個月中遇到了 TempDB DDL 爭用問題。伺服器將遇到等待資源 2:1:103 的爭用（等待類型為 PAGELATCH_EX）。
當伺服器負載正常時，該問題似乎偶爾發生。我一直在監視“破壞臨時表”的速率，當我們在 2:1:103 出現 PAGELATCH_EX 問題時，它可以跳到 5,000+。從我讀到的內容來看，這個計數器大部分時間應該是 0，但我們的似乎大部分時間都保持在 300-1100 之間。只有當系統上的使用者很少時，計數器才會變為 0。
如何縮小導致 tempdb 上 DDL 爭用的範圍，而無需在乾草堆中尋找針？
我已經看到了這個問題，最終發布的修復它實際上是我使用 Microsoft CSS 的直接結果。沒有針對此修復的公共知識庫文章。請確保您已將Service Pack 4和最新的累積更新應用到 SQL Server（在撰寫本文時，它是累積更新 #3 (9.00.5259)）。
在發布修補程序之前，Microsoft 的建議是停止創建 #temp 表（很像KB #916086）。由於這將意味著大量重寫數十個報告程序，因此我的解決方法（無論跟踪標誌或臨時文件佈局如何）是每隔一個週末重新啟動我們的集群。呸。
為了跟踪 tempdb 的使用情況，有幾個腳本可以提供幫助，例如查看 Adam Machanic 的sp_whoIsActive，具體來說：
還有來自@SQLSoldier 的這個腳本（以及評論中的腳本）：
我會確保你所有的游標都在使用
LOCAL STATIC READ_ONLY FORWARD_ONLY（參見this和this），並查看是否有任何已知的昂貴查詢廣泛使用#temp表/@table變數、CTE，或者可能包含不必要的排序或導致雜湊連接…所有這些都可能導致問題（我懷疑你會找到一個黃金原因）。作為“物有所值”的起點，最簡單的徹底修復將是使用適當且廉價的游標選項而不是預設值。與此同時，我會 (a) 安裝 CU#3 並 (b) 呼叫 PSS。告訴他們您正在執行一個非常具體的修復，該修復已被確認為錯誤並作為私有修補程序發布給其他使用者：“VSTS #109112 - 臨時表延遲刪除不適用於某些工作負載。” 您最初可能需要支付案件費用，但由於這是一個錯誤，因此應退還費用。
您可能需要跟踪標誌 1118
首先請參閱Paul Randal 關於 tempdb 的神話，以及他的TF 1118 文章
TF 在KB 328551中進行了描述
我對此沒有直接經驗，但這聽起來像我讀過的