BACKUP WITH CHECKSUM 無法替代 DBCC CHECKDB：三大關鍵原因深度解析

結論先行

BACKUP WITH CHECKSUM 絕不能替代 DBCC CHECKDB。 雖然備份時加上 WITH CHECKSUM 會驗證所有已配置頁面的校驗和，但存在三大根本缺口：

原因一：舊版升級資料庫可能有頁面未啟用校驗和

從 SQL Server 2000 或更早版本升級的資料庫，頁面校驗和預設關閉。啟用後，只有後續寫入的新頁面才會計算校驗和。舊頁面若損壞，I/O 子系統不會區分，備份時也無法偵測這些無校驗和頁面的損壞。

原因二：備份頻率無法滿足一致性檢查最佳實務

• 完整備份間隔通常較長（如每月），而 DBCC CHECKDB 最佳實務建議每週執行一次。
• 差異備份僅檢查已變更頁面的校驗和，未變更頁面不會被掃描。

原因三：無法偵測記憶體中頁面損壞（最危險）

若記憶體晶片或 Windows 進程導致記憶體中頁面損壞，寫回磁碟時會重新計算校驗和，導致磁碟上呈現「校驗和正確但資料邏輯錯誤」的頁面。唯有 DBCC CHECKDB 能發現此類邏輯不一致。

建議

務必定期執行 DBCC CHECKDB。對於超大資料庫（VLDB），可參考〈CHECKDB From Every Angle: Consistency Checking Options for a VLDB〉採用分段檢查策略。