您现在的位置：程式碼之家 >> 數據庫知識 > >> SQL Server 資料庫 >> 關於SqlServer

SQL Server 2000 資料庫修復實戰：823 錯誤 (Torn Page) 從診斷到恢復

編輯：關於SqlServer

某 POS 專案環境：Windows 2000 Server + SQL Server 2000 SP3，RAID5 (5×36GB)，資料庫約 5GB。備份策略：每日磁帶全備 + 夜間硬碟全備 (MASTER/MSDB/POS_DB)。

故障現場

日期：2003-12-26 13:00
現象：所有 POS 當機、伺服器極慢
重啟時 RAID 卡報警
Windows 系統日誌：
  Error 823, Severity 24, State 2
  I/O error (torn page) detected during read at offset 0x0000001bf96000 in file 'D:\DATA\POS_DB.mdf'
SQL Server 錯誤日誌：
  2003-12-10 03:34:22.23 spid56 Error: 823, Severity: 24, State: 2
  I/O error (torn page) detected during read at offset 0x00000074964000 in file 'D:\DATA\POS_DB.mdf'

錯誤 823 根因分析

I/O 邏輯檢查失敗：Windows 讀/寫 API 呼叫成功，但資料邏輯檢查失敗 (如頁面不完整/撕裂頁)。

硬體層面：磁碟控制器快取未寫入、RAID 卡電池失效、磁碟壞軌
作業系統層面：檔案系統錯誤、驅動程式 Bug
SQL Server 層面：頁面檢驗和 (CHECKSUM/TORN_PAGE_DETECTION) 發現不一致

標準排查流程 (Microsoft 官方建議)

DBCC CHECKDB：DBCC CHECKDB (POS_DB) WITH NO_INFOMSGS, ALL_ERRORMSGS
- 若報錯 → 依錯誤類型修復 (參考下節)
- 若無錯誤 → 檢查 Windows 系統事件日誌、磁碟診斷、聯繫硬體廠商
檢查版本：SELECT @@VERSION 確認 ≥ 8.00.2039 (SP3)，否則必須打補丁
硬體診斷：RAID 卡日誌、磁碟 SMART、控制器快取策略 (建議 Write-Through + BBU)

修復策略決策樹

DBCC 結果	修復選項	風險/代價
無錯誤	監控、硬體排查、考慮遷移	潛在風險未除
非叢集索引錯誤	`DBCC CHECKDB (..., REPAIR_REBUILD)`	安全，僅重建索引
叢集索引/資料頁錯誤	`REPAIR_ALLOW_DATA_LOSS` (最後手段)	資料遺失，必須備份後執行
系統表/關鍵頁錯誤	從乾淨備份還原	最安全，依賴備份可用性

本案實際處理

立即離線資料庫，複製 .mdf/.ldf 至獨立磁碟保全現場
執行 DBCC CHECKDB 發現資料頁撕裂，非系統表
嘗試 REPAIR_REBUILD 無效
評估業務影響：POS 交易系統容忍度極低，決定從前夜硬碟全備還原 (RPO ≈ 12小時)
還原流程：RESTORE DATABASE POS_DB FROM DISK='...' WITH REPLACE, RECOVERY
應用交易日誌備份 (若有) 將資料推進至故障點前
驗證關鍵業務表資料完整性，協助業務方核對缺失交易
同步更換 RAID 卡電池、啟用控制器 Write-Through、排程定期 DBCC CHECKDB

經驗總結與預防清單

☐ RAID 控制器 BBU 狀態監控 (每日巡檢)
☐ 磁碟 SMART 定期掃描
☐ 排程 DBCC CHECKDB (建議週執行，維護窗口)
☐ 啟用 PAGE_VERIFY CHECKSUM (SQL 2005+ 預設，2000 需 ALTER DATABASE)
☐ 備份策略：每日全備 + 15-30 分鐘交易日誌備份 (RPO 可控)
☐ 異地備份/磁帶輪換 (7 天循環)
☐ 災難演練：每季模擬還原驗證備份可用性
☐ 硬體生命週期管理：磁碟/控制器主動更換

823 錯誤是硬體/IO 子系統發出的紅色警訊，**備份可用性與定期一致性檢查**是唯一可靠防線。