dbcc checkdb 執行了很長時間，50% 的時間
我有一個夜間維護工作（主要取自 ola hallengren 維護包），它執行數據庫備份並對每個數據庫進行完整性檢查。
完整性檢查部分線上執行，針對生產數據庫，通常在大約 2.5 小時內完成 - 但有時它執行的時間要長得多（在某些情況下 12 小時以上）。
在掛起的日子與不掛起的日子沒有任何其他計劃的作業或其他活動正在執行，而且它通常掛起的數據庫只有大約 170gb。
我查看了我的等待統計資訊：
我的寫作停滯不前：
但我不是受過培訓的 DBA，我不確定如何處理這些資訊，或者我是否應該在哪裡尋找這個特定問題。
從評論中添加的附加資訊
sys.dm_exec_query_memory_grants
請求的_記憶體_kb = 31678040 授予的_記憶體
_kb = 31678040
所需的_記憶體_kb = 512
sys.dm_exec_requests
授予查詢記憶體 = 3959755
SQL Server 數據庫大小和記憶體
伺服器上所有數據庫的總大小約為 500 GB，但它阻塞的特定數據庫為 169.6 GB。分配給 SQL 的最大伺服器記憶體為 224 GB，總 VM 記憶體為 265 GB。
在那些需要這麼長時間的情況下，CHECKDB 是否有錯誤？在這些情況下，錯誤日誌文件中有什麼有用的嗎？
如果 CHECKDB 發現錯誤，它可能會進行“深入研究”以進一步調查（遍歷索引的鍊錶而不是僅檢查點陣圖，此處提到：https ://www.sqlskills.com/blogs/paul/checkdb -從每個角度完整描述所有檢查數據庫階段/）。
我看起來’Avg Stall（ms）‘非常高，我認為建議讀取<15ms和寫入<1ms，並且某些臨時文件的平均值為355ms。
您可以在 DBCC 執行時使用 perfmon 測量磁碟延遲：https ://docs.microsoft.com/sv-se/archive/blogs/askcore/measuring-disk-latency-with-windows-performance-monitor-perfmon
如果磁碟有問題，那麼將數據、日誌和 tempdb 文件保存在不同的（物理）磁碟上可能會有所幫助。