磁碟的平均寫入延遲峰值比平時多。需要幫助找到罪魁禍首
我們最近報告的磁碟寫入延遲有所增加。雖然我們的監控團隊沒有確認來自哪個驅動器，但在進行一些 dmv 查詢時，我看到
tempdb平均等待寫入時間約為 32 毫秒。同樣在一周的tempdb使用情況下，我的意思是可用的可用空間已從 300 GB 下降到 50 GB 以下。我懷疑這個尖峰可能來自
tempdb. 該環境混合了 OLTP 和倉庫人員在查找實時數據時查詢數據以進行大選擇，以防 LS 備用數據庫不可用。我的問題是如何檢查
tempdb是否會導致此峰值？這些選擇查詢也會導致
tempdb寫入延遲嗎？這些選擇查詢在超過 TB 數據的表上執行，使用者可以根據我所看到的情況進行部分查詢，例如 order by 和 group by。但我不確定如何證明它們是導致突然飆升的原因。
我的問題是如何檢查 TempDB 中的內容是否會導致此峰值？
要分析這些查詢對 tempdb 的影響，您可以使用sp_whoisactive，因為它輸出的資訊之一是 tempdb 的使用：
- **這些列中最令人困惑的是那些與 tempdb 相關的列。**每列報告一些 8 KB 頁面。這
$$ tempdb_allocations $$列直接從與 tempdb 相關的 DMV 收集，並指示 由於臨時表、LOB 類型、假離線或其他 使用者而
在 tempdb 中分配了多少頁。這
$$ tempdb_current $$列是通過從分配
數中減去 tempdb DMV 報告的已釋放頁面資訊來計算的。看到大量的分配與
少量的目前頁面意味著您的查詢可能會猛烈抨擊
tempdb，但不會導致它增長。查看大量
目前頁面意味著您的查詢可能對
您一直注意到的所有這些自動增長負責。
另一種表明您有與 tempdb 相關的問題的方法是sp_BlitzCache™ Result: TempDB Spills。正如該頁面所說：
要查找導致溢出的查詢，您有多種選擇——您可以擷取和檢查實際執行計劃，或者您可以通過擴展事件收集交換溢出事件。Paul White 在他的回復中涵蓋了您的選擇，其中涉及到 tempdb 的雜湊/排序溢出的頻率是多少？
那些選擇查詢也會導致 TempDB 寫入延遲。這些選擇查詢在超過 TB 數據的表上執行，使用者可以根據我所看到的情況進行部分查詢，例如 order by 和 group by。
當然可以。如果您檢查tempdb 數據庫文件，您會看到它儲存了以下對象：
- 數據庫引擎創建的內部對象。它們包括：
用於儲存假離線、游標、排序和臨時大對象 (LOB) 儲存的中間結果的工作表。
用於散列連接或散列聚合操作的工作文件。
創建或重建索引（如果指定了 SORT_IN_TEMPDB）或某些 GROUP BY、ORDER BY 或 UNION 查詢等操作的中間排序結果。