Oracle Cloud配置DG需确保主备库私网双向TCP 1521端口连通，VCN对等连接状态为PEERED，安全列表精确放行对方CIDR的入站TCP 1521，listener.ora与tnsnames.ora均填私网IP且HOST非localhost，DB_UNIQUE_NAME主备必须不同而SERVICE_NAME可相同，log_archive_dest_2须用TNS别名并配VALID_FOR，同时设置IPQOS=LOWEST避免MTU丢包。
Oracle Cloud上配置DG需要哪些网络打通前提
必须让主库和备库的数据库实例能双向tcp连通，且端口开放策略要精确到1521（或自定义监听端口），不能只靠vcn对等连接或安全列表放行“全部icmp”。
常见错误是只配了VCN对等连接，却忘了在两个VCN的安全列表里分别添加入站/出站规则——比如主库VCN要允许来自备库VCN CIDR的1521入站，备库VCN也要允许来自主库VCN CIDR的1521出站（实际是双向，但安全列表是单向控制）。
- 确认两个VCN已通过
VCN Peering建立对等关系，且状态为PEERED - 检查主库所在子网的安全列表：入站规则需含源CIDR（备库VCN）、目标端口
1521、协议TCP - 检查备库所在子网的安全列表：入站规则需含源CIDR（主库VCN）、目标端口
1521、协议TCP - 用
telnet <备库私网IP> 1521从主库主机测试；反向再测一次，别只信ping通
DG中tnsnames.ora与listener.ora的IP该填私网还是公网
一律填私网IP。Oracle DG流量不走互联网，也不经过NAT网关或负载均衡器，填公网IP会导致ORA-12541: TNS:no listener或日志里反复报connection refused。
容易被忽略的是：OCI里计算实例默认只有私网IP，即使你绑定了弹性公网IP（EIP），数据库监听仍只绑定在私网接口上。所以listener.ora里的HOST必须写实例的私网IP（如10.0.1.15），不是EIP；tnsnames.ora中ADDRESS下的HOST也必须对应对方实例的私网IP。
-
listener.ora中LISTENER部分的HOST值，应为本机私网IP，不是localhost或127.0.0.1 -
tnsnames.ora中主库连接备库的条目，HOST填备库实例私网IP；备库连主库同理 - 改完
listener.ora后必须执行lsnrctl reload，不是stop/start，避免中断已有连接 - 验证用
tnsping <tns_alias>，看到OK且延迟在毫秒级才算通
DB_UNIQUE_NAME和SERVICE_NAME在跨云DG中的命名陷阱
这两个参数不一致会直接导致ALTER DATABASE RECOVER MANAGED STANDBY DATABASE卡住，后台日志反复报ORA-16778: redo transport error，但错误本身不提示根本原因。
核心原则：主库和备库的DB_UNIQUE_NAME必须不同（如prod和prod_dg），但SERVICE_NAME可以相同（比如都叫prod_svc），只要它们各自监听器里注册的服务名与数据库实际SERVICE_NAMES参数一致即可。很多人误以为SERVICE_NAME也必须唯一，结果改乱了应用连接串。
- 查主库当前值：
SELECT NAME, DB_UNIQUE_NAME, SERVICE_NAMES FROM V$DATABASE; - 备库的
DB_UNIQUE_NAME必须在CREATE CONTROLFILE或DUPLICATE TARGET DATABASE FOR STANDBY时指定，不能后期ALTER -
SERVICE_NAMES参数可动态改：ALTER SYSTEM SET SERVICE_NAMES='prod_svc' SCOPE=BOTH;，改后lsnrctl status应能看到该服务已注册 - 确保主备库的
LOG_ARCHIVE_CONFIG包含双方DB_UNIQUE_NAME，例如：'DG_CONFIG=(prod,prod_dg)'
OCI上DG同步慢或归档无法传输的典型IP配置疏漏
不是带宽小，而是log_archive_dest_2里URL写的地址不可达，或者没开归档传输认证。最常踩的坑是：用了ASYNC模式但没配VALID_FOR，导致主库尝试往备库传归档时被拒绝。
另一个隐形问题是OCI计算实例的MTU默认是9000（Jumbo Frame），而某些本地IDC网络MTU是1500，混合云场景下若中间链路有设备不支持分片，大归档日志就会丢包，表现为LGWR进程持续重试、V$ARCHIVE_DEST_STATUS里ERROR列出现ORA-12535或timeout。
-
log_archive_dest_2必须用TNS别名，不要写直连字符串，例如：'SERVICE=prod_dg ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=prod_dg' - 确认主库
LOG_ARCHIVE_DEST_STATE_2为ENABLE，且ARCHIVE_LAG_TARGET不宜设过高（如3600），否则掩盖传输问题 - 在主备库都执行
ALTER SYSTEM SET IPQOS=LOWEST SCOPE=BOTH;，强制降MTU协商优先级，避免Jumbo Frame引发丢包 - 查传输状态：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;，别只看STATUS=VALID，重点盯ERROR列
混合云DG真正卡点不在Oracle配置，而在网络层是否真正“透明”——VCN对等、安全列表、监听绑定、MTU、TNS解析，五者缺一不可。少验一个，就可能花半天排查ORA-16057。
