最近在update某张表时突然提示了个比较少见的错误，ORA-01591,这个问题跟平时的锁还有点不一样，下面一起来看看吧~
思路
这个错误是由于分布式事务引起，而不是普通的锁引起的，检查一般对象数据表锁定，只需要检查v$locked_object和v$transaction视图，就可以定位到具体的SQL语句和操作人等信息。
select*fromgv$locked_object; select*fromgv$transaction;
使用oerr工具查看该错误编号
oerrora1591 01591,00000,"lockheldbyin-doubtdistributedtransaction%s" //*Cause:Tryingtoaccessresourcethatislockedbyadeadtwo-phasecommit //transactionthatisinpreparedstate. //*Action:DBAshouldquerythepending_trans$andrelatedtables,andattempt //torepairnetworkconnection(s)tocoordinatorandcommitpoint. //Iftimelyrepairisnotpossible,DBAshouldcontactDBAatcommit //pointifknownorenduserforcorrectoutcome,oruseheuristic //defaultifgiventoissueaheuristiccommitorabortcommandto //finalizethelocalportionofthedistributedtransaction.
简单的说，01591错误的原因是该对象被一个处在“in-doubt”状态的分布式事务锁定。分布式事务使用的是“two-phase commit”二阶段提交技术。解决该问题的方法就是查看内部表pending_trans$，确定分布式事务信息。这种状态的事务主要是由于在进行分布式事务时候，发生网络突发中断的情况，引起分布式事务无法正常结束，等待中断节点的事务响应。于是，各节点的事务所锁定的表就不会被释放掉。
处理方法
rollbackforce'20.13.14721';
Rollback force的参数是DBA_2PC_PENDING中记录本地事务信息的编号即LOCAL_TRAN_ID。
处理还是比较简单的，这里顺便分享下分布式事务的相关知识点。
分布式事务相关知识点
分布式事务，简单来说，是指一个事务在本地和远程执行，本地需要等待确认远程的事务结束后，进行下一步本地的操作。如通过dblink update远程数据库的一行记录，如果在执行过程中网络异常，或者其他事件导致本地数据库无法得知远程数据库的执行情况，此时就会发生in doublt的报错。此时需要dba介入，且需要分多种情况进行处理。
Oracle会自动处理分布事务，保证分布事务的一致性，所有站点全部提交或全部回滚。一般情况下，处理过程在很短的时间内完成，根本无法察觉到。
但是，如果在commit或rollback的时候，出现了连接中断或某个数据库 站点CRASH的情况，则提交操作可能会无法继续，此时DBA_2PC_PENDING和DBA_2PC_NEIGHBORS中会包含尚未解决的分布事务。 对于绝大多数情况，当恢复连接或CRASH的数据库重新启动后，会自动解决分布式事务，不需要人工干预。只有分布事务锁住的对象急需被访问，锁住的回滚段阻止了其他事务的使用，网络故障或CRASH的数据库的恢复需要很长的时间等情况出现时，才使用人工操作的方式来维护分布式事务。 手工强制提交或回滚将失去二层提交的特性，Oracle无法继续保证事务的一致性，事务的一致性应由手工操作者保证
使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY，可以使Oracle不再自动解决分布事务，即使网络恢复连接或者CRASH的数据库重新启动。
ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢复自动解决分布事务。
两个重要的视图
1. DBA_2PC_PENDING
DBA_2PC_PENDING:列出所有的悬而未决的事务﹐此视图在末填入悬而未决的事务之前是空的﹐解决这后也被清空。
DBA_2PC_PENDING的STATE列的说明
SELECT * FROM DBA_2PC_PENDING;
2. DBA_2PC_NEIGHBORS
DBA_2PC_NEIGHBORS:列出所有获得的(从远程客户)和送出的(给远程服务器)悬而未决的事务﹐也表示该本地节点是不是事务的提交点站点。
