SQL Server 系統表損壞修復實戰：DBCC 無法修復的 Object ID 2 不一致錯誤

遇到 DBCC CHECKDB 回報系統表 sysindexes (Object ID 2) 存在 text/ntext/image 節點引用不匹配錯誤，且標準修復指令無效時，可嘗試「清空問題表數據 → 重新匯入」的繞過策略。

錯誤現象

Server: Msg 8929, Level 16, State 1
Object ID 2: Error in text ID 177078272 owned by RID = (1:627:1) id = 1899153811 indid = 10.

Server: Msg 8961, Level 16, State 1
Table error: Object ID 2. text/ntext/image node at page (1:875), slot 0, text ID 177078272 
does not match reference at page (1:500), slot 14.

CHECKDB found 0 allocation errors and 2 consistency errors in table 'sysindexes' (Object ID 2).

排查與修復過程

1. 執行 DBCC CHECKDB ('DBName', REPAIR_ALLOW_DATA_LOSS) 仍無法修復系統表錯誤。
2. 根據錯誤訊息中的 RID (1:627:1) 定位至 sysobjects 特定記錄，對比同結構健康資料庫，發現單一欄位值異常（疑為受影響資料列計數）。
3. 嘗試 TRUNCATE TABLE 該表（非系統表，而是業務表），再執行 CHECKDB → 錯誤消失。
4. 驗證：將該表數據備份至臨時表 → TRUNCATE TABLE → 從臨時表 INSERT 回寫 → CHECKDB 回報 0 錯誤。

核心洞見

• 系統表 (Object ID 2) 錯誤往往由**使用者表數據頁損壞**波及引起，而非系統表本身邏輯錯誤。
• DBCC CHECKTABLE 對系統表可能不報錯，需結合應用程式報錯點反推受影響業務表。
• 「清空並重載業務表數據」可重建底層資料頁與系統表引用一致性，屬繞過修復而非根治。

操作腳本範例

-- 1. 確認問題表 (假設為 dbo.ProblemTable)
SELECT * INTO #Tmp_Backup FROM dbo.ProblemTable;

-- 2. 清空表 (重新分配資料頁，斷開舊引用鏈)
TRUNCATE TABLE dbo.ProblemTable;

-- 3. 重新寫入乾淨數據
INSERT INTO dbo.ProblemTable SELECT * FROM #Tmp_Backup;

-- 4. 驗證
DBCC CHECKDB ('DBName') WITH NO_INFOMSGS;
-- 應回報: 0 allocation errors, 0 consistency errors

預防與最佳實務

• 定期執行 DBCC CHECKDB 並建立告警，早期發現一致性錯誤。
• 啟用頁面驗證：ALTER DATABASE [DB] SET PAGE_VERIFY CHECKSUM;
• 硬體層面：使用 ECC 記憶體、RAID 冗餘、UPS 防止寫入中斷。
• 備份策略：完整+差異+記錄備份，確保可時間點還原至損壞前狀態。

此類系統表引用不匹配雖罕見，但一旦發生極具誤導性。記住：先查業務表，再修系統表，往往能以最小代價恢復服務。