在 Microsoft® SQL Server™ 2000 中，可以在用戶使用數據庫時運行 DBCC CHECKDB，因為 DBCC CHECKDB 在檢查每個數據庫表時在表上控制的鎖的類型均更改。
在 SQL Server 7.0 和早期版本中，DBCC CHECKDB（依次在數據庫的每個表上運行 DBCC CHECKTABLE 和 CHECKALLOC）常常在表上控制共享鎖 (S)，因而阻塞了所有的數據修改語言 (DML) 語句。
在 SQL Server 2000 中，當檢查表時 DBCC CHECKDB 在表上控制架構鎖以防止元數據的更改，因而允許在正在檢查的表上使用除任何數據定義語言 (DDL) 語句之外的 DML 語句。該變化對於決定何時運行 DBCC CHECKDB 提供了更大的靈活性，因為 DBCC CHECKDB 並不完全拒絕用戶對系統的使用。
DBCC CHECKDB 是大量占用 CPU 和磁盤的操作。每一個需要檢查的數據頁都必須首先從磁盤讀入內存。另外，DBCC CHECKDB 使用 tempdb 排序。
如果在 DBCC CHECKDB 運行時動態執行事務，那麼事務日志會繼續增長，因為 DBCC 命令在完成日志的讀取之前阻塞日志截斷。
建議在服務器負荷較少的時候運行 DBCC CHECKDB。如果在負荷高峰期運行 DBCC CHECKDB，那麼事務吞吐量性能和 DBCC CHECKDB 完成時間性能都會受到影響。
要獲得好的 DBCC 性能的一些建議
在系統使用率較低時運行 CHECKDB。
請確保未同時執行其它磁盤 I/O 操作，例如磁盤備份。
將 tempdb 放到單獨的磁盤系統或快速磁盤子系統中。
允許 tempdb 在驅動器上有足夠的擴展空間。使用帶有 ESTIMATE ONLY 的 DBCC 估計 tempdb 將需要多少空間。
避免運行占用大量 CPU 的查詢或批處理作業。
在 DBCC 命令運行時，減少活動事務。
使用 NO_INFOMSGS 選項顯著減少處理和 tempdb 的使用。
考慮使用帶有 PHYSICAL_ONLY 選項的 DBCC CHECKDB 來檢查頁和記錄首部的物理結構。當硬件導致的錯誤被置疑時，這個操作將執行快速檢查。
