ora-01591错误源于未决分布式事务（in-doubt状态）持有的锁，需通过查询dba_2pc_pending定位事务id，再执行rollback force或commit force解决；若失败，须检查reco进程、网络连通性，并在禁用分布式恢复后人工干预清理。
ORA-01591 这类错误不是 Java 层抛出的运行时异常，而是 Oracle 数据库在执行 SQL 时返回的致命错误，Java 应用只是被动接收并封装成 SQLException。想“解决 Java 异常”，本质是解决底层分布式事务卡在 IN-DOUBT 状态导致的锁冲突。
查不到锁却报 ORA-01591，说明是分布式事务残留锁
典型现象：执行 UPDATE 或 DELETE 报 ORA-01591: lock held by in-doubt distributed transaction %s，但查 v$locked_object 和 v$transaction 为空。这是因为锁来自未完成的两阶段提交（2PC）事务，状态存在 pending_trans$ 而非常规事务表。
- 必须先确认该事务 ID 是否真正在
dba_2pc_pending中存在（注意：RAC 环境需查所有实例） -
SELECT * FROM dba_2pc_pending WHERE local_tran_id = '13.3.394006';—— 若无结果，不代表事务已清理干净，可能基表残留 - 不要直接 kill session 或重启数据库，这类操作无法释放 2PC 悬疑锁
rollback force 失败时，优先检查 reco 进程和网络连通性
rollback force 'x.x.x' 卡住或报 ORA-02058（no prepared transaction found），通常意味着协调者节点不可达或本地记录不完整。
- 检查
reco进程是否启用：SELECT * FROM v$bgprocess WHERE pname = 'RECO'; - 确认数据库间 dblink 可连通：
SELECT * FROM dual@remote_db;—— 若失败，reco无法推进事务清理 - 若远程库已下线或网络永久中断，不能依赖自动恢复，必须人工干预
手工清理 pending_trans$ 前必须禁用分布式恢复
直接删 sys.pending_trans$ 会触发 Oracle 内部校验失败，甚至引发 ORA-600。正确路径是先停掉自动恢复机制。
- 执行
ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY;（必须有SYSDBA权限） - 再插入缺失的预备记录（如
INSERT INTO pending_trans$ (...) VALUES (...);），让 Oracle 认为该事务“存在”才能被 force 操作识别 - 之后再执行
COMMIT FORCE 'x.x.x';或ROLLBACK FORCE 'x.x.x'; - 最后
ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY;
Java 应用侧能做的只有规避和快速失败
Java 本身无法修复 Oracle 的悬疑事务，但可以减少触发概率和缩短故障感知时间。
- 避免在事务中混用本地 SQL 和 dblink 操作；如必须跨库，优先用应用层异步 + 补偿（如 Seata AT 模式），而非原生 XA
- 设置合理的 JDBC 连接超时和 socketTimeout，防止网络中断后连接长期 hang 住，间接导致 2PC 卡死
- 捕获
SQLException并检查getSQLState()是否为"08006"或错误码1591，记录事务 ID 后告警，交由 DBA 处理
真正卡住的点永远在数据库底层：pending_trans$ 记录不全、reco 进程失能、dblink 不可达——这些都不是 Java 重试或换驱动能绕开的。应用能做的上限，就是别让一个悬疑事务拖垮整个业务线。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
