ORA-01591: lock held by in-doubt distributed transaction 20.25.280352

客户一套oracle11.2.0.4rac一体机，应用侧抛来一个报错

最开始看上去像是事务锁，但是问客户知道这是查的哪张表，客户反馈知道，就通过一般性事务去查了该表的锁：

SELECT /*+ rule */ lpad(' ',decode(l.xidusn ,0,3,0))||l.oracle_username User_name,
o.owner,o.object_name,o.object_type,s.sid,s.serial#
FROM v$locked_object l,dba_objects o,v$session s
WHERE l.object_id=o.object_id
AND l.session_id=s.sid 
AND upper(o.OBJECT_NAME) LIKE '%TO_ALERT_SMS_%'
ORDER BY o.object_id,xidusn DESC ;
发现该语句没有任何返回，意思到这可能不是一般的事务锁。

搜索该问题，发现有篇文章

在Oracle中，分布式事务ORA-01591错误如何解决？ - 云+社区 - 腾讯云

里面也是这种报错，是一种分布式事务2节点提交锁，大意就是，通过dblink连接另一个数据库的表是，对另一个数据库的表进行dml操作，同时也可能在同一个事务中对本库中的本地表做事务提交操作，那么对于dblink的表，需要确保远端的数据库也要提交，那么在本地像远端确认提交的时候，先由本地库发一个prepare的确认信息，远端回复prepare了以后，本地在执行commit信息；此种情况就是在本地执行commit以后，此时远端库还没有完全commit，此时网络中断，导致本地库该表是commit状态，但是远端库还是prepare状态，一般来讲，此时如果源端得到的事务信息是全的，那么数据库不需要人为干预，能够自动根据事务信息进行提交操作，但是出现这个问题的时候，基本就表示提交的事务信息不足以让远端库执行提交操作，所以此时这种事务就需要人为干预了。

对于这样的事务，在运气好的情况下，对于这个事务，只能通过连接网络或者强制提交回退事务来结束。可以使用COMMIT FORCE或者ROLLBACK FORCE来进行处理，在这里，进行回滚操作，如下所示：

ROLLBACK FORCE '20.25.280352';

如果能执行过去，那么该

而我这次情况下，执行这条语句会夯，客户反馈执行了8个小时，命令还未返回。