ORA-01591: lock held by in-doubt distributed transaction 22.10.18863

ORA-01591: lock held by in-doubt distributed transaction 22.10.18863


Fri Apr 04 13:53:49 2014
DISTRIB TRAN 44444444.DFA786C45D1C944F97483DAF3B2517E400000000
  is local tran 22.10.18863 (hex=16.0a.49af)
  change pending prepared tran, scn=7624887939 (hex=1.c67a8e83)
  to     pending forced rollback tran, scn=7624887939 (hex=1.c67a8e83) 
DISTRIB TRAN 44444444.6DBDCB0C8348A54F86BCCEF4ACB3287000000000
  is local tran 41.32.5321 (hex=29.20.14c9)
  change pending prepared tran, scn=7624887955 (hex=1.c67a8e93)
  to     pending forced rollback tran, scn=7624887955 (hex=1.c67a8e93) 
DISTRIB TRAN 44444444.B8D1A3A2DE4F4845A064FCA2080BA9F400000000
  is local tran 63.5.3631 (hex=3f.05.e2f)
  change pending prepared tran, scn=7624887953 (hex=1.c67a8e91)
  to     pending forced rollback tran, scn=7624887953 (hex=1.c67a8e91) 
  
$oerr ora 1591
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.
$


解决办法如下：
1、使用Oracle DBA用户，查询如下数据字典：select * from dba_2pc_pending
2、强制Rollback或者Commit该事务：
select 'commit force '''|| local_tran_id||''';' from dba_2pc_pending;
select 'rollback force '''|| local_tran_id||''';' from dba_2pc_pending;


此时通过state=committed, 表示此session已提 交,只是在提交后，接受不到global session的transaction信息了,所以产生异步lock，此时对一般不造成table的lock。
通过调用 execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.10.255'）； 可解决此问题。
当然state还有以下几种状态：
alter system switch logfile;
collecting:在收集数据过程中,产生异常
解决方法： execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.10.255');
prepared： 在接受到异步commit/rollback指令前， 产生异常
解决方法： rollback force tran_id/commit force tran_id; -- 可根据异步transaction的状况决定使用方法。
forced rollback： 在使用rollback force出现
解决方法： execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.10.255');
forced commit：在使用commit force出现
解决方法： execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.10.255');


使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY，可以使Oracle不再自动解决分布事务，即使网络恢复连接或者CRASH的数据库重新启动。
ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢复自动解决分布事务。


  总的来说ORA-1591的产生原因是分布式事务失败，失败的原因很多，比如网络问题、XA资源管理器存在BUG等，都可能引起失败。一旦分布式事务失败，本地事务中，如果有一个事务挣处于活跃状态，那么该事务相关的数据就会被锁定（无论读写都会被锁定），如果访问这个事务关联的数据，就会报ORA-1591。一般情况下，ORA-1591可以自动的解开，SMON会在一定时间周期内检查DBA_2PC_PENDING，找出需要回退的事务，并进行自动的恢复。这里就有几个问题，由于分布式事务超时判断以及RECO处理周期的关系，一般来说事务自动恢复的时间为1分钟以上，较长的可以达到5-10分钟。可能会对生产系统造成比较大的影响。为了加快解锁，可以使用手工处理。这个时候可以使用ROLLBACK FORCE或者COMMIT FORCE。


有时候由于分布式事务恢复出现故障，会出现数据字典不一致，此时该分布式事务就无法正常解除，需要手工干预来处理。


分析方法：
1、检查分布式事务的状态：
SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, HOST, COMMIT#
FROM DBA_2PC_PENDING
WHERE LOCAL_TRAN_ID = '报错的本地事务号'


2、检查分布式事务相关其他节点的情况：
SELECT LOCAL_TRAN_ID, IN_OUT, DATABASE, INTERFACE FROM DBA_2PC_NEIGHBORS;


3、检查本地回滚段：
例如：分布式事务73.11.124822 锁定了。查看下73号回滚段的情况:
      SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */
             KTUXESTA Status,
             KTUXECFL Flags
      FROM x$ktuxe
      WHERE ktuxesta!='INACTIVE'
            AND ktuxeusn= 回滚段编码73