最近在更新某张表的时候，突然提示一个比较少见的错误，ORA-01591，这个问题和平时的锁有点不一样，一起来看看一起看看~思路这个错误是分布式事务引起的，不是普通的锁。查看通用对象数据表锁，只需要查看v$locked_object和v$transaction视图，定位具体的SQL语句和操作人等信息。选择*FORTGV$locked_object;select*fortgv$thraction;使用oerr工具工具工具该该该错误错误错误错误错误错误错误错误错误错误编号错误错误错误错误编号该错误错误编号,andattempt//torepairnetworkconnection(s)tocoordinatorandcommitpoint.//Iftimelyrepairisnotpossible,DBAshouldcontactDBAatcommit//pointifknownorenduserforcorrectoutcome,oruseheuristic//defaultifgiventoissueaheuristiccommitorabortcommandto//finalizethelocalportionofthedistributedtransaction.简单的说，01591错误的原因是该对象被一个处在“in-doubt”状态的分布交易锁。分布式事务使用“两阶段提交”两阶段提交技术。这个问题的解决方法是查看内表pending_trans$来确定分布式事务信息。该状态下的交易主要是由于分布式交易过程中网络突然中断，导致分布式交易无法正常结束，等待中断节点的交易响应。因此，各个节点的事务锁定的表不会被释放。处理方式为rollbackforce'20.13.14721'；Rollbackforce参数为DBA_2PC_PENDING中记录的本地事务信息的个数，即LOCAL_TRAN_ID。处理起来比较简单，这里顺便介绍一些关于分布式事务的知识点。分布式事务相关知识点分布式事务，简单来说就是一个事务在本地和远程执行，本地需要等待远程事务结束的确认，才能进行本地的下一步操作。例如通过dblink更新远程数据库中的一行记录，如果执行过程中网络异常，或者其他事件导致本地数据库无法获知远程数据库的执行状态，此时就会出现in-double错误时间。这个时候就需要DBA介入，需要分多种情况进行处理。Oracle会自动处理分布式事务，保证分布式事务的一致性，所有站点都会提交或回滚。通常，处理会在很短的时间内完成，以至于根本不会引起注意。但是，如果在提交或回滚过程中连接中断或某个数据库站点发生CRASH，则提交操作可能无法继续。此时，DBA_2PC_PENDING和DBA_2PC_NEIGHBORS将包含未解决的分布式事务。大多数情况下，当连接恢复或CRASH数据库重启时，分布式事务会自动解决，无需人工干预。只有当分布式事务锁定的对象需要紧急访问，锁定的回滚段阻止其他事务使用，网络故障或CRASH数据库的恢复需要很长时间等情况下，手动操作用于维护。分布式事务。手动强制提交或回滚会失去两层提交的特性，Oracle无法继续保证事务的一致性。交易的一致性应由人工操作员保证。使用ALTERSYSTEMDISABLEDISTRIBUTEDRECOVERY来防止Oracle自动解析分布式事务。即使网络连接恢复或者CRASH数据库重启。ALTERSYSTEMENABLEDISTRIBUTEDRECOVERY恢复自动解决分布式事务。两个重要的视图1.DBA_2PC_PENDINGDBA_2PC_PENDING：列出所有待处理的事务。这个view在pendingtransactions被填满之前是空的，resolved之后也是清空的。DBA_2PC_PENDING的STATE列说明SELECT*FROMDBA_2PC_PENDING;2.DBA_2PC_NEIGHBORSDBA_2PC_NEIGHBORS：列出所有获得（从远程客户端）和发送（到远程服务器）的未决事务，同时指出本地节点是否是事务的提交站点。
