DBCC CHECKDB 執行最佳實務：降低影響、加速檢查

DBCC CHECKDB 檢查資料庫邏輯/物理一致性，屬高 CPU/IO 操作。SQL 2000 改為 Schema Lock (Sch-S) 允許 DML 並發，但仍需謹慎排程。

資源消耗特性

• 所有資料頁需讀入記憶體 → 高 IO。
• 使用 tempdb 排序 → 需足夠 tempdb 空間與 IO。
• 執行期間阻塞記錄檔截斷 → 記錄檔持續增長。

七大建議

1. 離峰時段執行：避開業務尖峰。
2. 避免同時進行其他磁碟 IO 作業 (備份、索引重建、大量匯入)。
3. tempdb 放置獨立高速磁碟/陣列 (SSD/RAID 10)，預先擴大避免自動成長。
4. 預估 tempdb 空間：DBCC CHECKDB ('DB') WITH ESTIMATEONLY。
5. 避免同時執行高 CPU 查詢/批次作業。
6. 減少作用中交易：長交易會阻礙記錄檔截斷並增加檢查負擔。
7. 使用 NO_INFOMSGS：僅回報錯誤，大幅減少訊息處理與 tempdb 使用。
8. 僅檢查物理結構 PHYSICAL_ONLY：DBCC CHECKDB ('DB') WITH PHYSICAL_ONLY, NO_INFOMSGS，快速偵測硬體導致的頁面/記錄頭損壞，耗時大幅縮減。

排程範例 (SQL Agent 作業)

-- 每週日 02:00 執行完整檢查
DBCC CHECKDB ('YourDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;
-- 每日 03:00 僅物理檢查
DBCC CHECKDB ('YourDB') WITH PHYSICAL_ONLY, NO_INFOMSGS;

錯誤處理

• 發現錯誤 → 先備份 → DBCC CHECKDB ... REPAIR_REBUILD (無資料遺失) → 再嘗試 REPAIR_ALLOW_DATA_LOSS (最後手段)。
• 定期測試備份還原 + CHECKDB，驗證備份可用性。