摘要：
在访问某些表的特定行时报ora-01591错误
select * from bf_income_expenses_t
where account_id = 36816153
and user_id = 39964213
and city_code = '185'
ora-01591: 锁定已被有问题的分配事务处理72.0.1608712挂起
sql> select count(*) from unitele.bi_mqsync_source_control_t1;
ora-01591: 锁定已被有问题的分配事务处理72.0.1608712挂起
由于该表是业务关键表，部分前台业务受到影响。
关键词：ora-01591 dba_2pc_pending 分布式事务
1.故障分析
首先，在遇到ora错误时，我们不可能知道每个ora错误都是什么意思，所以通过oracle的联机文档查错误的cause和action可以让我们初步了解该错误。
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.
oracle对ora-01591错误的描述是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’该错误是由访问一个处于prepared状态的二阶段事务所持有锁的资源造成的。
下面简单介绍一下分布式事务。
分布式事务，简单来说，是指一个事务在本地和远程执行，本地需要等待确认远程的事务结束后，进行下一步本地的操作。如通过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清除分布式事务信息。
有关分布式事务的详细信息请参阅oracle联机文档.
当前的分布式事务处于two-phase commit机制中的prepared阶段，这个阶段事务已经在表上加锁了，现在我们要访问这些表，但事务没有结束，一直持有锁，导致访问资源失败报ora-01591。(在这里需要指出：分布式事务所持有的锁之所以堵塞读操作，是因为oralce不知道该显示哪个版本的数据) 如果结束这个事务，那相应的锁也会释放，这样就能解决这个问题。我们知道要结束一个事务有两种办法：commit和rollback。现在我们尝试结束这个事务：
commit force '72.0.1608712';
ora-02058: no prepared transaction found with id 72.0.1608712
报错并没有发现prepared状态的事务，由于该事务是分布式事务，我们首先想到的是dba_2pc_pending这个试图
sql> select * from dba_2pc_pending;
no rows selected
该试图并没有查到信息，所以我们无法用commit force结束这个分布式事务，那么现在我们查看是否存在该事务，通过实际报错，我们可以清晰的看到事务号为72.0.1608712，该事务在72号回滚段的0号事务槽上并且序列号是1608712，这时查询一个基表x$ktuxe，看看72号回滚段上是否有该事务。
sql> select ktuxeusn, ktuxeslt, ktuxesqn, /* transaction id */
2 ktuxesta status,
3ktuxecfl flags
4from x$ktuxe
5where ktuxesta!='inactive'
6 and ktuxeusn= 72;
ktuxeusnktuxesltktuxesqn statusflags
---------- ---------- ---------- ---------------- ------------------------
7201608712 preparedsco|col|rev|dead
通过x$ktuxe这个基表，我们看到确实存在这个事务，而且是prepared状态。