回滾段架構與循環使用
- 由連續 Extent 組成，Head 指向當前寫入 Extent，Tail 指向最早未提交事務的回滾資訊。
- Extent 循環使用：寫滿移至下一 Extent；若下一 Extent 含 Tail（活躍事務），則動態分配新 Extent（擴展）。
- 8i 限制：單一事務僅能使用一個回滾段；多事務可共用 Extent，但 Active 事務不共用 Block。
一致性讀流程與 ORA-01555 觸發點
- 讀取資料區塊 → 行頭 → ITL 取得交易 ID (XID)。
- 查交易表：若已提交且 Commit SCN < Query SCN → 區塊清理，重新驗證。
- 若交易表找不到 XID（Slot 被覆蓋）：比較 Query SCN 與 Control SCN（該回滾段最早可見提交 SCN）。
- Query SCN ≤ Control SCN → 無法判斷提交順序 → ORA-01555。
- Query SCN > Control SCN → 接受區塊，標記 ITL "U" (Upper bound commit)。
- 讀取 Undo 區塊 (Uba) → 比對 XID：不符 → 回滾資訊被覆蓋 → ORA-01555。
- XID 符合 → 記憶體複製區塊，從 Head 應用 Undo 重構舊映像；鏈式追溯至無前驅區塊為止。
兩大 ORA-01555 成因與對策
| 成因 | 現象 | 對策 |
|---|
| 交易表 Slot 被覆蓋 | 長查詢遇到高併發短事務，Slot 循環複用 | 增加回滾段數量，降低 Slot 複用頻率 |
| Undo 區塊被覆蓋 | 長查詢所需的 Undo 已被後續事務覆寫 | 增加回滾段大小/Extent 數，延長 Undo 保留時間 |
診斷利器：Event 1555 Trace
event = "1555 trace name processstate forever, level 10"
-- 產生 Process State Dump，顯示嘗試回滾的區塊類型
-- 若為回滾段 Header Block，證實為 Slot 覆蓋問題
參考：IXORA Undo 詳細說明
延遲區塊清理 的關聯
查詢遇到未清理區塊時觸發清理動作，同樣需讀取 Undo 重構舊映像，故同樣面臨 ORA-01555 風險。
總結
ORA-01555 本質是「查詢 SCN 落在 Undo 保留窗口之外」。8i 以手動管理回滾段為主，透過增加段數量與尺寸、調整 MAXEXTENTS、監控 V$ROLLSTAT 緩解。9i 引入自動 Undo 管理與 UNDO_RETENTION 參數，從根本上簡化了此類問題的處理。
