ORA-01591: 鎖被未決分散式交易處理解決方案，ora-01591交易處理

ORA-01591: 鎖被未決分散式交易處理解決方案，ora-01591交易處理

   現場報有一個功能走不下去，後台日誌報錯：java.sql.SQLException: ORA-01591: 鎖被未決分散式交易處理 657.7.39336 持有。

   解決方案：

   rollback force '657.7.39336';--執行可能會比較慢

   執行完成後，查詢DBA_2PC_PENDING，

    select * from DBA_2PC_PENDING s  where s.local_tran_id='657.7.39336';

    657.7.39336 SP4GD.a6dfea73.657.7.39336forced rollback no 2015-6-17 5:28:05 2015-6-17 10:44:33 2015-6-17 5:28:05 oracle UNKNOWN SCDB02 LCA_ZC       14456764049772
   或者
   delete from sys.pending_trans$ where local_tran_id = '657.7.39336'; 
   delete from sys.pending_sessions$ where local_tran_id = '657.7.39336'; 
   delete from sys.pending_sub_sessions$ where local_tran_id ='657.7.39336'; 
   commit; 
   Commit force '657.7.39336' 
   exec dbms_transaction.purge_lost_db_entry('657.7.39336');

DBA_2PC_PENDING describes distributed transactions awaiting recovery.描述等待恢複的分散式交易。

LOCAL_TRAN_ID   String of form: n.n.n; n is a number
GLOBAL_TRAN_ID Globally unique transaction ID
STATE        Collecting, prepared, committed, forced commit, or forced rollback
MIXED        YES indicates part of the transaction committed and part rolled back
ADVICE        C for commit, R for rollback, else NULL
TRAN_COMMENT Text for commit work comment text
FAIL_TIME Value of SYSDATE when the row was inserted (transaction or system recovery)
FORCE_TIME Time of manual force decision (null if not forced locally)
RETRY_TIME Time automatic recovery (RECO) last tried to recover the transaction
OS_USER        Operating system-specific name for the end-user
OS_TERMINAL Operating system-specific name for the end-user terminal
HOST        Name of the host machine for the end-user
DB_USER        Oracle user name of the end-user at the topmost database
COMMIT#        Global commit number for committed transactions

這個錯誤是什麼意思呢？

[oracle@standby ~]$  oerr ora 01591
01591, 00000, "lock held by in-doubt distributed transaction %s"
// *Cause:  Trying to access resource that is locked by a dead two-phase commit
//          transaction that is in prepared state.
// *Action: DBA should query the pending_trans$ and related tables, and attempt
//          to repair network connection(s) to coordinator and commit point.
//          If timely repair is not possible, DBA should contact DBA at commit
//          point if known or end user for correct outcome, or use heuristic
//          default if given to issue a heuristic commit or abort command to
//          finalize the local portion of the distributed transaction.

兩階段交易認可(2PC)
兩階段交易認可協議可以保證資料的強一致性，許多分布式關係型資料管理系統採用此協議來完成分散式交易。它是協調所有分布式原子事務參與者，並決定提交或取消（復原）的分布式演算法。同時也是解決一致性問題的演算法。該演算法能夠解決很多的臨時性系統故障（包括進程、網路節點、通訊等故障），被廣泛地使用。但是，它並不能夠通過配置來解決所有的故障，在某些情況下它還需要人為的參與才能解決問題。
顧名思義，兩階段交易認可分為以下兩個階段：
1）Prepare Phase （準備節點）
2）Commit Phase （提交階段）
1）Prepare Phase
在要求階段，協調者將通知事務參與者準備提交或取消事務，然後進入表決過程。在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。

為了完成准準備階段，除了commit point site外，其它的資料庫節點按照以下步驟執行：
每個節點檢查自己是否被其它節點所引用，如果有，就通知這些節點準備提交（進入 Prepare階段）。
每個節點檢查自己啟動並執行事務，如果發現本地啟動並執行事務沒有修改資料的操作（唯讀），則跳過後面的步驟，直接返回一個read only給全域協調器。
如果事務需要修改資料，則為事務分配相應的資源用於保證修改的正常進行。
當上面的工作都成功後，給全域協調器返回準備就緒的資訊，反之，則返回失敗的資訊。
2) Commit Phase
在該階段，協調者將基於第一個階段的投票結果進行決策：提交或取消。若且唯若所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。參與者在接收到協調者發來的訊息後將執行響應的操作。
 
提交階段按下面的步驟進行：
全域協調器通知 commit point site 進行提交。
commit point site 提交，完成後通知全域協調器。
全域協調器通知其它節點進行提交。
其它節點各自提交本地事務，完成後釋放鎖和資源。
其它節點通知全域協調器提交完成。
3）結束階段
全域協調器通知commit point site說所有節點提交完成。
commit point site資料庫釋放和事務相關的所有資源，然後通知全域協調器。
全域協調器釋放自己持有的資源。
分散式交易結束
一般情況下，兩階段交易認可機制都能較好的運行，當在事務進行過程中，有參與者宕機時，重啟以後，可以通過詢問其他參與者或者協調者，從而知道這個事務到底提交了沒有。當然，這一切的前提都是各個參與者在進行每一步操作時，都會事先寫入日誌。


唯一一個兩階段交易認可不能解決的困境是：當協調者在發出commit 訊息後宕機，而唯一收到這條命令的一個參與者也宕機了，這個時候這個事務就處於一個未知的狀態，沒有人知道這個事務到底是提交了還是未提交，從而需要資料庫管理員的介入，防止資料庫進入一個不一致的狀態。當然，如果有一個前提是：所有節點或者網路的異常最終都會恢複，那麼這個問題就不存在了，協調者和參與者最終會重啟，其他節點也最終會收到commit 的資訊。這也符合CAP理論。http://blog.itpub.net/48010/viewspace-1016050/

下面簡單介紹一下分散式交易。

分散式交易，簡單來說，是指一個事務在本地和遠程執行，本地需要等待確認遠端事務結束後，進行下一步本地的操作。如通過dblink update遠端資料庫的一行記錄，如果在執行過程中網路異常，或者其他事件導致本機資料庫無法得知遠端資料庫的執行情況，此時就會發生in doublt的報錯。此時需要dba介入，且需要分多種情況進行處理。

分散式交易的Two-Phase Commit機制，會經曆3個階段：

1.PREPARE PHASE：

1.1 決定哪個資料庫為commit point site。（注，參數檔案中commit_point_strength值高的那個資料庫為commit point site）

1.2 全域協調者（Global Coordinator）要求所有的點（除commit point site外）做好commit或者rollback的準備。此時，對分散式交易的表加鎖。

1.3 所有分散式交易的節點將它的scn告知全域協調者。

1.4 全域協調者取各個點的最大的scn作為分散式交易的scn。

至此，所有的點都完成了準備工作，我們開始進入COMMIT PHASE階段，此時除commit point site點外所有點的事務均為in doubt狀態，直到COMMIT PHASE階段結束。

2.COMMIT PHASE：
2.1 Global Coordinator將最大scn傳到commit point site，要求其commit。
2.2 commit point嘗試commit或者rollback。分散式交易鎖釋放。
2.3 commit point通知Global Coordinator已經commit。
2.4 Global Coordinator通知分散式交易的所有點進行commit。

3.FORGET PHASE：
3.1 參與的點通知commit point site他們已經完成commit，commit point site就能忘記（forget）這個事務。
3.2 commit point site在遠端資料庫上清除分散式交易資訊。
3.3 commit point site通知Global Coordinator可以清除本地的分散式交易資訊。
3.4 Global Coordinator清除分散式交易資訊