現(xiàn)場報有一個功能走不下去，后臺日志報錯：java.sql.SQLException: ORA-01591: 鎖被未決分布式事務(wù)處理 657.7.39336 持有。

解決方案：

rollback force '657.7.39336';--執(zhí)行可能會比較慢

執(zhí)行完成后，查詢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.描述等待恢復(fù)的分布式事務(wù)。



這個錯誤是什么意思呢？

[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)
兩階段提交協(xié)議可以保證數(shù)據(jù)的強一致性，許多分布式關(guān)系型數(shù)據(jù)管理系統(tǒng)采用此協(xié)議來完成分布式事務(wù)。它是協(xié)調(diào)所有分布式原子事務(wù)參與者，并決定提交或取消（回滾）的分布式算法。同時也是解決一致性問題的算法。該算法能夠解決很多的臨時性系統(tǒng)故障（包括進程、網(wǎng)絡(luò)節(jié)點、通信等故障），被廣泛地使用。但是，它并不能夠通過配置來解決所有的故障，在某些情況下它還需要人為的參與才能解決問題。
顧名思義，兩階段提交分為以下兩個階段：
1）Prepare Phase （準(zhǔn)備節(jié)點）
2）Commit Phase （提交階段）

1）Prepare Phase
在請求階段，協(xié)調(diào)者將通知事務(wù)參與者準(zhǔn)備提交或取消事務(wù)，然后進入表決過程。在表決過程中，參與者將告知協(xié)調(diào)者自己的決策：同意（事務(wù)參與者本地作業(yè)執(zhí)行成功）或取消（本地作業(yè)執(zhí)行故障）。

為了完成準(zhǔn)準(zhǔn)備階段，除了commit point site外，其它的數(shù)據(jù)庫節(jié)點按照以下步驟執(zhí)行：
每個節(jié)點檢查自己是否被其它節(jié)點所引用，如果有，就通知這些節(jié)點準(zhǔn)備提交（進入 Prepare階段）。
每個節(jié)點檢查自己運行的事務(wù)，如果發(fā)現(xiàn)本地運行的事務(wù)沒有修改數(shù)據(jù)的操作（只讀），則跳過后面的步驟，直接返回一個read only給全局協(xié)調(diào)器。
如果事務(wù)需要修改數(shù)據(jù)，則為事務(wù)分配相應(yīng)的資源用于保證修改的正常進行。
當(dāng)上面的工作都成功后，給全局協(xié)調(diào)器返回準(zhǔn)備就緒的信息，反之，則返回失敗的信息。

2) Commit Phase
在該階段，協(xié)調(diào)者將基于第一個階段的投票結(jié)果進行決策：提交或取消。當(dāng)且僅當(dāng)所有的參與者同意提交事務(wù)協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者取消事務(wù)。參與者在接收到協(xié)調(diào)者發(fā)來的消息后將執(zhí)行響應(yīng)的操作。

提交階段按下面的步驟進行：
全局協(xié)調(diào)器通知 commit point site 進行提交。
commit point site 提交，完成后通知全局協(xié)調(diào)器。
全局協(xié)調(diào)器通知其它節(jié)點進行提交。
其它節(jié)點各自提交本地事務(wù)，完成后釋放鎖和資源。
其它節(jié)點通知全局協(xié)調(diào)器提交完成。

3）結(jié)束階段
全局協(xié)調(diào)器通知commit point site說所有節(jié)點提交完成。
commit point site數(shù)據(jù)庫釋放和事務(wù)相關(guān)的所有資源，然后通知全局協(xié)調(diào)器。
全局協(xié)調(diào)器釋放自己持有的資源。

分布式事務(wù)結(jié)束
一般情況下，兩階段提交機制都能較好的運行，當(dāng)在事務(wù)進行過程中，有參與者宕機時，重啟以后，可以通過詢問其他參與者或者協(xié)調(diào)者，從而知道這個事務(wù)到底提交了沒有。當(dāng)然，這一切的前提都是各個參與者在進行每一步操作時，都會事先寫入日志。

唯一一個兩階段提交不能解決的困境是：當(dāng)協(xié)調(diào)者在發(fā)出commit 消息后宕機，而唯一收到這條命令的一個參與者也宕機了，這個時候這個事務(wù)就處于一個未知的狀態(tài)，沒有人知道這個事務(wù)到底是提交了還是未提交，從而需要數(shù)據(jù)庫管理員的介入，防止數(shù)據(jù)庫進入一個不一致的狀態(tài)。當(dāng)然，如果有一個前提是：所有節(jié)點或者網(wǎng)絡(luò)的異常最終都會恢復(fù)，那么這個問題就不存在了，協(xié)調(diào)者和參與者最終會重啟，其他節(jié)點也最終會收到commit 的信息。這也符合CAP理論。
http://blog.itpub.net/48010/viewspace-1016050/

下面簡單介紹一下分布式事務(wù)。

分布式事務(wù)，簡單來說，是指一個事務(wù)在本地和遠程執(zhí)行，本地需要等待確認(rèn)遠程的事務(wù)結(jié)束后，進行下一步本地的操作。如通過dblink update遠程數(shù)據(jù)庫的一行記錄，如果在執(zhí)行過程中網(wǎng)絡(luò)異常，或者其他事件導(dǎo)致本地數(shù)據(jù)庫無法得知遠程數(shù)據(jù)庫的執(zhí)行情況，此時就會發(fā)生in doublt的報錯。此時需要dba介入，且需要分多種情況進行處理。

分布式事務(wù)的Two-Phase Commit機制，會經(jīng)歷3個階段：

1.PREPARE PHASE：

1.1 決定哪個數(shù)據(jù)庫為commit point site。（注，參數(shù)文件中commit_point_strength值高的那個數(shù)據(jù)庫為commit point site）

1.2 全局協(xié)調(diào)者（Global Coordinator）要求所有的點（除commit point site外）做好commit或者rollback的準(zhǔn)備。此時，對分布式事務(wù)的表加鎖。

1.3 所有分布式事務(wù)的節(jié)點將它的scn告知全局協(xié)調(diào)者。

1.4 全局協(xié)調(diào)者取各個點的最大的scn作為分布式事務(wù)的scn。

至此，所有的點都完成了準(zhǔn)備工作，我們開始進入COMMIT PHASE階段，此時除commit point site點外所有點的事務(wù)均為in doubt狀態(tài)，直到COMMIT PHASE階段結(jié)束。

2.COMMIT PHASE：
2.1 Global Coordinator將最大scn傳到commit point site，要求其commit。
2.2 commit point嘗試commit或者rollback。分布式事務(wù)鎖釋放。
2.3 commit point通知Global Coordinator已經(jīng)commit。
2.4 Global Coordinator通知分布式事務(wù)的所有點進行commit。

3.FORGET PHASE：
3.1 參與的點通知commit point site他們已經(jīng)完成commit，commit point site就能忘記（forget）這個事務(wù)。
3.2 commit point site在遠程數(shù)據(jù)庫上清除分布式事務(wù)信息。
3.3 commit point site通知Global Coordinator可以清除本地的分布式事務(wù)信息。
3.4 Global Coordinator清除分布式事務(wù)信息

以上3個階段，在任何一個階段的前、中、后發(fā)生失敗都會導(dǎo)致two phase commit失敗，一般來說，Oracle后臺進程REC0會自動恢復(fù)事務(wù)，只有在分布式事務(wù)鎖住的對象急需被訪問，鎖住的回滾段阻止了其他事務(wù)的使用，網(wǎng)絡(luò)故障或CRASH的數(shù)據(jù)庫的恢復(fù)需要很長的時間等情況出現(xiàn)時，才需要使用人工操作的方式來維護分布式事務(wù)，而分布式事務(wù)失敗的情況也比較復(fù)雜，需要針對不同的情形采取相應(yīng)的措施，Oracle中提供了視圖dba_2pc_pending和dba_2pc_neighbors供用戶查看分布式事務(wù)的相關(guān)信息，通常two phase commit失敗有如下5種情況：

1.prepare階段沒準(zhǔn)備好就失敗了，global coordinator正在等待各個站點返回已準(zhǔn)備好的通知，處于collecting狀態(tài)，dba_2pc_pending試圖中的state列的值是collecting，各個站點什么都沒發(fā)生，無需執(zhí)行任何操作，在本地數(shù)據(jù)庫執(zhí)行exec dbms_transaction.purge_lost_db_entry(’transaction_id’)清除in_doubt狀態(tài)的分布式事務(wù)記錄就可以了

2.prepare階段完成時發(fā)生失敗，global coordinator處于prepared狀態(tài)，已經(jīng)加上分布鎖，等待提交，遠程commit point site已經(jīng)自動回滾，此時需要在global coordinator上執(zhí)行rollback force ‘transaction_id’，然后清除in_doubt狀態(tài)的分布式事務(wù)記錄

3.commit point site執(zhí)行commit完成后其他站點尚未commit時發(fā)生失敗，這時需要在其他站點執(zhí)行commit force ‘transaction_id’,'commit#’，注意后面的commit#使用較高的commit#，可以查詢各個站點的dba_2pc_pending試圖的commit#列得到，然后清除in_doubt狀態(tài)的分布式事務(wù)記錄

4.所有站點commit成功，進入forget階段時發(fā)生失敗，數(shù)據(jù)已經(jīng)一致，只需在各站點清除in_doubt狀態(tài)的分布式事務(wù)記錄就可以了

5.commit point site完成forget階段，其他站點沒完成forget，只需在其他站點清除in_doubt狀態(tài)的分布式事務(wù)記錄就可以了

來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/31397003/viewspace-2153090/，如需轉(zhuǎn)載，請注明出處，否則將追究法律責(zé)任。

總結(jié)

以上是生活随笔為你收集整理的ORA-01591: 锁被未决分布式事务处理解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。