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$两个表中插入数据。