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理论。

ORA-01591: 锁被未决分布式事务处理解决方案

标签：

原文地址：http://blog.csdn.net/stevendbaguo/article/details/46533449