Oracle OBJ$ / I_OBJ4 ORA-08102 索引不一致故障深度修復實錄

Oracle OBJ$ / I_OBJ4 ORA-08102 索引不一致故障深度修復實錄

本文記錄一起真實生產環境案例：OBJ$ 表與 I_OBJ4 索引因 DATAOBJ# 不一致導致 ORA-08102: index key not found，進而引發 ORA-00604 遞迴錯誤，導致無法建立資料表。詳細記錄從診斷、BBED 修改資料塊、嘗試標記壞塊、最終透過刪除資料字典記錄並配合 Bootstrap$ 核心索引恢復的完整過程，供 DBA 參考。

一、故障現象

SQL> CREATE TABLE t1 AS SELECT * FROM dual;
ORA-00604: error occurred at recursive SQL level 1
ORA-08102: index key not found, obj# 39, file 1, block 93842 (2)

查詢 DBA_OBJECTS 確認 obj#=39 為 I_OBJ4 索引。

二、根因分析

1. 使用 MINUS 對比全表掃描與索引掃描結果，發現 _NEXT_OBJECT 記錄在 OBJ$ 中 DATAOBJ#=97094，但在 I_OBJ4 中為 97109，雙方不一致。
2. 進一步檢查 MAX(DATAOBJ#) 走 INDEX FULL SCAN (MIN/MAX) 僅回傳 96815，證明索引鏈結結構已損壞，非單純資料不一致。
3. Trace 檔確認錯誤發生於 I_OBJ4 索引塊 93842，鍵值包含 97109。

三、修復嘗試歷程

1. BBED 修改 OBJ$ 表資料塊

• 定位 ROWID=AAAAASAABAAAADxAAb 對應 FILE#=1, BLOCK#=241, ROW#=27。
• 將 DATAOBJ# 從 97094 (C3 0A 47 5F) 修改為 97109 (C3 0A 48 0A)，並 SUM APPLY 更新檢查碼。
• 驗證 MINUS 查詢無差異，但 ANALYZE TABLE SYS.OBJ$ VALIDATE STRUCTURE CASCADE 仍報 ORA-01499，建表仍失敗。

2. 標記索引塊為壞塊並屏蔽

• BBED 修改 BLOCK#=93842 尾部檢查碼由 01 改 02，經 DBVERIFY 確認標記成功。
• 啟動帶 _corrupted_rollback_segments 等隱含參數的 PFILE，嘗試繞過壞塊。
• 結果：錯誤轉為 ORA-01578，無法繞過，證明索引邏輯損壞非單一塊問題。

3. 終極方案：刪除 I_OBJ4 字典記錄 + Bootstrap$ 恢復

• 因索引鏈結損壞已影響核心字典操作，手工修補成本極高且風險大。
• 採用「刪除 I_OBJ4 字典記錄 → 重建核心 Bootstrap$ 索引（I_OBJ1, I_USER1, I_FILE#_BLOCK#, I_IND1, I_TS#, I_CDEF1 等）→ 開啟資料庫」策略。
• 最終資料庫正常開啟，建表功能恢復，業務零資料遺失。

四、關鍵教訓

1. ORA-08102 可能源自索引結構邏輯損壞，而非單純資料不一致；MINUS 對比無差異不代表索引健康。
2. BBED 修改資料塊無法修復索引鏈結，若 MAX() 走 MIN/MAX 掃描結果異常，說明分支節點或葉節點鏈結斷裂。
3. 標記壞塊無法繞過字典核心索引錯誤，系統表空間核心物件損壞需從字典層面重建。
4. 備份策略至關重要：若有近期 RMAN 備份，優先考慮 RESTORE/RECOVER TABLESPACE SYSTEM 或 FLASHBACK DATABASE。

五、預防建議

• 定期執行 ANALYZE TABLE SYS.OBJ$ VALIDATE STRUCTURE CASCADE 及 DBMS_REPAIR.CHECK_OBJECT 檢核字典健康。
• 啟用 DB_BLOCK_CHECKING=FULL、DB_BLOCK_CHECKSUM=FULL 提早發現塊損壞。
• 保留足夠保留期的 RMAN 備份與歸檔日誌，確保核心表空間可時間點恢復。

此案例再次證明：字典核心物件損壞屬於最高等級災難，修復需極度謹慎，條件允許下優先以備份恢復為主，手工 BBED 修補僅作最後手段。