Oracle 分散式交易跨節點執行，透過兩階段提交 (2PC) 確保全域一致性。本文釐清三大角色（Local/Global Coordinator、Commit Point Site），詳細拆解 PREPARE → COMMIT → FORGET 三階段流程、SCN 同步機制、IN-DOUBT 狀態成因與自動/手動恢復策略。
關鍵角色定義
| 角色 | 定義 | 職責 |
|---|
| Global Coordinator | 交易發起節點 | 協調全域交易，發起 PREPARE/COMMIT |
| Local Coordinator | 需參考其他節點資料完成本地操作的節點 | 執行本地分支，回應 PREPARE 狀態 |
| Commit Point Site | 最先 COMMIT/ROLLBACK 的節點 | 持有交易狀態資訊，永不進入 PREPARED，無 IN-DOUBT 風險 |
Commit Point Site 選擇機制
- 由初始化參數
COMMIT_POINT_STRENGTH 決定（值越大優先度越高）
- 原則：存放關鍵業務資料的節點 設高值，使其成為 Commit Point Site
- 交易狀態資訊儲存於該節點資料庫
三階段流程詳細拆解
階段一：PREPARE PHASE (投票階段)
- Global Coordinator 向所有參與節點發送
PREPARE 通知
- 各節點比較 SCN，取最大值作為全域 SCN
- 所有節點將變更寫入線上重做日誌（含 PREPARE 記錄）
- 對交易修改的表加分散式鎖，防止被讀寫
- 各節點向 Global Coordinator 回報「準備就緒」
門檻：所有節點必須完成上述步驟，才能進入 COMMIT 階段。
階段二：COMMIT PHASE (提交階段)
- Global Coordinator 通知 Commit Point Site 先行提交
- Commit Point Site 提交 → 釋放資源 → 回報完成
- Global Coordinator 通知其他節點提交
- 各節點在日誌追加「交易已提交」標記 → 回報完成
- 此時所有節點資料達成一致性
階段三：FORGET PHASE (清理階段)
- Global Coordinator 通知 Commit Point Site「所有節點已提交」
- Commit Point Site 清除交易狀態記錄 → 回報
- Global Coordinator 清除本地交易狀態記錄
- 兩階段提交完全結束
IN-DOUBT 狀態：成因與處理
成因
- COMMIT PHASE 完成前，發生節點故障、網路中斷、介質損壞
- 應用收到錯誤，交易狀態未定（已 PREPARED 但未 COMMIT/ROLLBACK）
自動恢復
- RECO (Recoverer) 背景進程定期掃描
DBA_2PC_PENDING
- 網路/節點恢復後，RECO 自動聯繫對端完成提交或回滾
需人工介入情境
- IN-DOUBT 交易鎖住關鍵表，導致應用無法運作
- 手動查詢：
SELECT * FROM DBA_2PC_PENDING;
- 手動提交：
COMMIT FORCE 'local_tran_id';
- 手動回滾：
ROLLBACK FORCE 'local_tran_id';
結語
分散式交易 = SCN 同步 + 重做日誌持久化 + 分散式鎖 + 狀態機。Commit Point Site 選擇關鍵在於業務資料重要性而非效能。IN-DOUBT 雖有 RECO 自動修復，但關鍵表長時間鎖定仍需人工介入。建立 DBA_2PC_PENDING 監控告警，縮短決策窗口。
- 上一篇文章： Oracle 海量資料快速轉移雙絕技：建新表直載與 APPEND 直寫，繞過 Redo 與 Undo
- 下一篇文章： Oracle 外部身份驗證實作指南：OS 驗證配置、ORA_DBA 群組、Remote_Login_Passwordfile 三模式與域用戶映射
Copyright ©
程式碼之家 All Rights Reserved
