攻克 ORA-600 [12700]：從索引重建到表重建的完整排查實錄

生產資料庫警報日誌大量出現 ORA-600 [12700]，特定 SQL 執行即觸發。本文詳細記錄從現象還原、分析驗證、多方嘗試至最終以表重建解決的完整過程，為同類內部錯誤提供診斷思路。

錯誤觸發 SQL

SELECT ID, AVERTEXID, AVERTEXTYPE, ZVERTEXID, ZVERTEXTYPE 
FROM PHYSICALCONNECTION 
WHERE (AVERTEXTYPE='C' AND AVERTEXID IN (840402))
   OR (ZVERTEXTYPE='C' AND ZVERTEXID IN (840402));

分析與驗證步驟

1. 拆解條件測試：單獨執行 OR 兩側條件、或以 UNION ALL 合併，均不報錯 → 問題在 OR 條件結合的執行計畫。
2. 結構驗證：ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE 無錯 → 資料結構完整。
3. 索引重建：重建該表所有 7 個索引 → 問題持續。
4. 事件追蹤：依 Metalink Note 337631.1 設定 10078 事件 → 無效。
5. ROWID 懷疑：參考 Note 155933.1，懷疑 ROWID 映射錯誤。

關鍵驗證：CTAS 建立新表

CREATE TABLE PHYSICALCONNECTION_BAK AS SELECT * FROM PHYSICALCONNECTION;

新表執行原 SQL **完全正常** → 確認問題在原表的資料區塊或 ROWID 映射層面。

解決方案：表重建

-- 1. 建立備份表
CREATE TABLE PHYSICALCONNECTION_BAK AS SELECT * FROM PHYSICALCONNECTION;

-- 2. 刪除原表
DROP TABLE PHYSICALCONNECTION;

-- 3. 重命名備份表
RENAME PHYSICALCONNECTION_BAK TO PHYSICALCONNECTION;

-- 4. 重建索引、授權、同義詞等相依物件
-- （交由開發團隊後續處理）

根因推測與預防

ORA-600 [12700] 通常與 KDSGRP（資料層掃描）模組中 ROWID 解析失敗有關，可能原因：

• 資料區塊損壞但未被偵測（如緩存層面的邏輯損壞）
• 遷移/匯入過程中 ROWID 映射異常
• 特定版本 Bug（查詢 Metalink 確認是否有適用補丁）

預防建議：定期執行 DBMS_REPAIR 檢查、重要表排程重建、啟用區塊校驗和 DB_BLOCK_CHECKING。

總結

面對 ORA-600 內部錯誤，系統性驗證（結構、索引、執行計畫、ROWID）比盲目套用補丁更有效。當 CTAS 新表可正常查詢時，果斷重建原表往往是最快、最徹底的解法。