Sql-Server
什麼會導致 DBCC CheckDB 比平時花費更長的時間？
我有一個維護任務，它
DBCC CHECKDB WITH PHYSICAL_ONLY在我的伺服器（SQL Server 2016 標準版）上的數據庫上執行。對於大約 120 個數據庫，這通常需要大約 7h30，這是可以接受的時間。但是偶爾（就像昨天一樣），在相同數量的數據庫上執行此操作需要 10 個小時。
從日誌中，我知道每個 DBCC CHECKDB 的執行時間都比平時長。不止一個 DBCC CHECKDB 花費了 3 個小時以上。都是單獨的 CHECKDB 多花了幾分鐘。
CHECKDB 在夜間執行，此時客戶端仍在使用數據庫，但活動較少。數據庫的大小有所增加，但不會導致增加 3 小時。
除了客戶在數據庫上的活動可能會導致一些延遲之外，還有什麼會導致 DBCC CHECKDB 比平時花費更長的時間？我至少需要向我的老闆解釋為什麼它偶爾會這樣做，然後又恢復到正常時間。
謝謝
很多選擇，很難推測：
- 磁碟的 IO 速度較慢，可能是由於 SAN 上其他地方的活動？
- 干擾盒子上的其他活動（使用者活動、維護工作、其他數據庫等）
- 盒子上的記憶體或 CPU 壓力（管理員在本地登錄讓事情繼續執行，大型 SSIS 包佔用 CPU 或本地記憶體）
縮小其中哪些可能並不容易，您可能必須打開一些長期執行的性能日誌並隨著時間的推移做一些趨勢。