DB_DOMAIN参数必须全局一致，否则两阶段提交失败；DB Link需用完整全局名且远程库应启用专用连接；XA事务需开启distributed_transactions和RECO进程，并避免同义词间接访问。
DB_DOMAIN 参数必须全局一致，否则两阶段提交直接失败
oracle 分布式事务依赖 db_domain 构建全局数据库名（db_name.db_domain），所有参与节点的 db_domain 值必须完全相同，包括大小写和空格。哪怕只有一台库设成 example.com，另一台是 example.com.（末尾多点），commit 时就会卡住或报 ora-02062: distributed recovery failed。
实操建议：
- 查当前值：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'db_domain'; - 修改需重启：在
init.ora或 SPFILE 中设db_domain='yourdomain.local'，不能用ALTER SYSTEM动态改 - 检查所有 DB Link 目标库的
GLOBAL_NAME：SELECT * FROM GLOBAL_NAME;，确保它等于DB_NAME.DB_DOMAIN - 测试前先用
SELECT * FROM ALL_DB_LINKS;确认 DB Link 指向的是完整全局名，不是只写DB_NAME
DB Link 必须用完整全局名，且远程库要开共享服务器或启用专用连接
创建 DB Link 时不写全 DB_NAME.DB_DOMAIN，两阶段提交会找不到协调者。更隐蔽的问题是：如果远程库启用了共享服务器模式（SHARED_SERVERS > 0），而本地发起分布式事务，Oracle 可能无法正确传递事务上下文，导致 ORA-02049: timeout: distributed transaction waiting for lock。
实操建议：
- 建 Link 时强制写全名：
CREATE DATABASE LINK remote_db CONNECT TO u IDENTIFIED BY p USING 'remote_tns';，同时确保remote_tns对应的TNSNAMES.ORA条目中SERVICE_NAME匹配远程库的GLOBAL_NAME - 远程库若用共享服务器，需在
listener.ora中为该服务显式配置(SERVER=DEDICATED)，或临时改用专用模式测试 - 验证 Link 是否真能走两阶段：执行
BEGIN INSERT INTO t@remote_db VALUES(1); COMMIT; END;，别只测SELECT
XA 事务不等于 Oracle 原生两阶段提交，混用会出错
如果你的应用通过 JDBC/ODBC 走 XA 接口（比如 WebLogic 的 JTA），但数据库侧没配 RECO 进程、没开 distributed_transactions 参数，或者 DB Link 没启用 SHARED_POOL 中的事务协调信息，就会出现 ORA-24777: use of non-migratable database link not allowed。这不是网络问题，是 Oracle 内部事务上下文无法跨进程迁移。
实操建议：
- 确认参数已开：
distributed_transactions至少设为 10（默认常为 0） -
RECO进程必须运行：SELECT * FROM V$BGPROCESS WHERE PNAME = 'RECO';应有记录 - 避免在 XA 事务里用同义词或视图间接访问 DB Link；必须直写
table@dblink - XA 开启后，
COMMIT实际分两轮：prepare 阶段所有节点锁资源并响应，commit 阶段才真正落盘——所以超时时间得调长，ALTER SYSTEM SET distributed_lock_timeout=600;
ORA-02056 和 ORA-02068 常因 TNS 解析或网络中断被误判为配置问题
看起来像 DB_DOMAIN 不对，实际可能是 TNS 别名解析到了错误 IP，或防火墙中途断开了 long-running 的两阶段握手包。这类错误往往在重试几次后突然成功，说明不是静态配置缺陷，而是运行时链路不稳定。
实操建议：
- 用
tnsping remote_tns检查解析结果，再用tracing模式抓包确认是否真连到目标实例：sqlplus /@remote_tns成功不代表分布式事务通 - 在
sqlnet.ora加：SQLNET.EXPIRE_TIME=10防连接假死，TRACE_LEVEL_CLIENT=16抓详细日志 - 不要依赖单次
COMMIT测试；分布式事务的可靠性体现在连续 100 次跨库更新+提交都不丢数据
真正难调的不是参数本身，是多个库之间时间不同步、归档模式不一致、甚至操作系统 ulimit 限制了 RECO 进程打开文件数——这些不会报明确错误，但会让两阶段提交随机 hang 在 prepare 阶段。
