SQL Server 2000 資料庫修復實戰：823 錯誤、分頁損毀、備份還原與 DBCC 緊急修復全紀錄

真實案例：POS 系統，SQL Server 2000 (SP3) on Windows 2000，RAID-5，5GB 資料庫。每日磁帶完備 + 夜間硬碟完備（雙重保險）。

故障爆發

2003-12-26 13:00 所有 POS 當機、伺服器極慢。重啟時 RAID 卡報警。事件檢視器與 SQL 錯誤日誌均出現：

Error: 823, Severity: 24, State: 2
I/O error (torn page) detected during read at offset 0x... in file 'D:\DATA\POS_DB.mdf'

823 錯誤：I/O 邏輯檢查失敗（分頁損毀）。Windows API 讀寫成功，但資料邏輯校驗失敗（如分頁撕裂）。

修復嘗試與決策

1. 嘗試 DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS：風險極高，可能進一步損壞資料。
2. 評估備份可用性：最近一次完備備份（磁帶/硬碟）時間點、交易記錄備份鏈完整性。
3. 決定方案：還原最近完備備份 → 套用後續交易記錄備份 → 將資料庫恢復至故障前一致狀態。

關鍵教訓

• 硬體層面：RAID 卡快取需電池保護（BBWC/FBWC），定期一致性檢查。
• 備份策略：完備+差異+記錄備份鏈完整，定期演練還原驗證（RESTORE VERIFYONLY）。
• 監控預警：設定 823/824/825 錯誤即時告警，首次出現即啟動損毀評估流程。
• 頁面驗證：資料庫選項 PAGE_VERIFY CHECKSUM (SQL 2005+) 能更早偵測分頁損毀。

總結

823 錯誤代表儲存子系統已產生靜默資料損毀。唯有經驗證的備份還原鏈能保證資料零損失恢復。DBCC 修復屬最後手段，必伴隨資料遺失風險。預防勝於治療：硬體防護、備份驗證、主動監控三位一體。