SQL Server 資料庫損毀偵測與修復完整指南：從 IO 子系統到 DBCC CHECKDB 實戰

前言：為何資料庫會損毀？

資料頁從記憶體 Buffer Pool 透過 Checkpoint / Lazy Writer 寫入持久化儲存，必須穿越：

1. Windows API
2. 防毒/加密中介層
3. 網路裝置 (非直連儲存)
4. SAN / RAID 控制器
5. 磁碟/SSD 實體媒體

任何一層發生電壓不穩、斷電、過熱、韌體 Bug、壞軌，皆可能導致頁面寫入錯誤。此外，人為編輯 MDF/NDF、未清理交易即刪除 LDF 亦屬常見人禍。

SQL Server 如何偵測頁面損毀？

頁面保護機制三選一

啟用 CHECKSUM 後，僅有新寫入頁面 會計算 checksum；既有資料頁需經 DBCC CHECKDB 或備份讀取才會驗證。

三大 IO 錯誤代碼

建立 SQL Server Agent 警示 針對 823/824 發送郵件，可第一時間知悉損毀。

備份端的 Checksum 防線

• BACKUP ... WITH CHECKSUM：讀取每頁重算 checksum，發現錯誤預設中止備份；加 CONTINUE_AFTER_ERROR 可強制完成但標記損毀。
• RESTORE VERIFYONLY WITH CHECKSUM：驗證備份檔完整性與頁面 checksum。
• 備份完成會對整個備份集再計算一組 checksum 存於備份標頭。

DBCC CHECKDB 核心用法與策略

基本語法

-- 僅顯示錯誤，抑制資訊訊息
DBCC CHECKDB WITH NO_INFOMSGS;

-- 指定資料庫
DBCC CHECKDB (YourDB) WITH NO_INFOMSGS, ALL_ERRORMSGS;

企業版平行執行與資料庫快照

• 企業版自動平行化，使用內建資料庫快照，不封鎖使用者查詢。
• 消耗大量 CPU/記憶體/IO，**務必安排在維護窗口或離峰時段**。

拆解子命令 (大型資料庫分散負載)

1. DBCC CHECKALLOC：配置頁一致性
2. DBCC CHECKTABLE：每張表邏輯一致性
3. DBCC CHECKCATALOG：中繼資料一致性
4. 系統表損毀僅能透過備份還原 (含 master、msdb、model)。

修復策略：依冗余層級遞減

1. 鏡像 / 可用性群組 自動頁面修復 (2008+ 鏡像、2012+ AG)：
   基於記錄重做，不會將損毀頁面複製到次要複本。主體遭遇 824 向鏡像/次要複本請求乾淨頁面。
2. 頁面級還原 (PAGE RESTORE)：
   RESTORE DATABASE [DB] PAGE='1:155' FROM DISK='backup.bak' WITH NORECOVERY...
   需完整備份鏈完整，Enterprise/Standard (2012+) 支援。
3. 非叢集索引損毀：DROP INDEX / CREATE INDEX 或 ALTER INDEX REBUILD 即可修復，無資料遺失。
4. 記錄鏈完整時的時間點還原：尾端記錄備份 → 還原至損毀前時間點。
5. 最後手段：DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS：
   需 SINGLE_USER 模式 (停機)，以刪除資料換取一致性，結果不可預測，執行前必須評估 SLA 與業務影響。

事前準備清單 (DBA 必做)

• ✅ 所有使用者資料庫啟用 PAGE_VERIFY CHECKSUM。
• ✅ 定期 BACKUP ... WITH CHECKSUM + RESTORE VERIFYONLY WITH CHECKSUM。
• ✅ 排程 DBCC CHECKDB WITH NO_INFOMSGS (大庫拆解子命令)。
• ✅ Agent 警示 823/824/825 郵件通知。
• ✅ 完整/差異/記錄備份鏈完整，並定期演練還原 (含頁面級)。
• ✅ 系統資料庫 (master, msdb, model) 同樣納入備份策略。

結語

資料庫損毀多源自 IO 子系統，偵測靠 CHECKSUM、DBCC CHECKDB、備份驗證三層防線；修復優先使用冗余 (HA/備份)，REPAIR_ALLOW_DATA_LOSS 為最後手段且意味著資料遺失。唯有完善的備份與監控，才能在災難發生時從容應對。