如何配置Oracle分布式事务_两阶段提交与DB

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 阶段。