共计 1739 个字符，预计需要花费 5 分钟才能阅读完成。
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 染指，且须要分多种状况进行解决。
分布式事务的，会经验 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 和 www.pizei.comrollback。当初咱们尝试完结这个事务：通过 x$ktuxe 这个基表，咱们看到的确存在这个事务，而且是 prepared 状态。
此时，咱们根本分明了这个问题的起因：当一个分布式事务死掉时，因为该事务没有失常完结，导致事务持有的锁始终没有开释，所以在拜访这个事务波及的资源时，申请不到锁资源，所以报 ORA-01591。因为是分布式事务，当在 dba_2pc_pending 中查问不到事务信息时，咱们是无奈通过 commit 或者 rollback 完结该事务。
所以，咱们目前的工作是模拟出这个分布式事务。因为 dba_2pc_pending 试图是依赖于 pending_trans$ 这个表，同时事务是与 session 关联在一起的，所以咱们须要手工往 pending_trans$ 和 pending_sessions$ 两个表中插入数据。
