dgmgrl连不上远程实例主因是tnsnames.ora与listener.ora配置不一致：tnsnames.ora需双向配置且service_name须与listener.ora中global_dbname完全一致（含大小写），并使用vip而非scan；listener.ora必须静态注册，含sid_name、oracle_home、global_dbname三项，且改后执行lsnrctl reload。
dgmgrl 连不上远程实例，90% 是 tnsnames.ora 和 listener.ora 两边没对齐，不是网络不通，也不是密码错。
tnsnames.ora 必须双向配全，且 SERVICE_NAME 要和静态注册的 GLOBAL_DBNAME 完全一致
很多人只在主库配了备库连接串，忘了备库也要能反向连回主库——DGMGRL 在 switchover 或 reinstate 时，会主动用本地 tnsnames.ora 解析目标库。解析失败直接报 ORA-12154（找不到服务名）或 ORA-12514（监听不认识这个服务）。
- 主库
$ORACLE_HOME/network/admin/tnsnames.ora中必须有类似STANDBY_DG的条目，SERVICE_NAME值设为STANDBY_DG（不是db_unique_name，也不是db_name） - 备库同理，必须有
PRIMARY_DG条目，SERVICE_NAME = PRIMARY_DG - 两个条目的
HOST必须填对方 VIP（RAC 环境下不能混用 SCAN），端口统一（比如都用1521，别一个用1521、一个用1522） - 大小写敏感：如果
GLOBAL_DBNAME = standby_dg，但tnsnames.ora里写的是SERVICE_NAME = STANDBY_DG，照样连不上
listener.ora 静态注册段必须显式写全 SID_NAME、ORACLE_HOME、GLOBAL_DBNAME
动态注册对 DGMGRL 不可靠：实例一重启，PMON 注册有延迟，DGMGRL 可能抢在注册完成前就发连接请求，报 ORA-12514；更糟的是，DG Broker 要求角色切换时监听能立刻拉起实例，这只能靠静态注册保证。
- 每个节点的
listener.ora里必须有SID_LIST_LISTENER段，不能只靠默认动态注册 - 每个
SID_DESC必须包含三项：SID_NAME（等于本机ORACLE_SID）、ORACLE_HOME（路径要绝对准确，别用变量）、GLOBAL_DBNAME（必须和对应tnsnames.ora条目的SERVICE_NAME字符完全一致） - 例如备库上配主库服务名，就得加一条：
(SID_DESC = (GLOBAL_DBNAME = PRIMARY_DG) (ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1) (SID_NAME = orcl1)) - 改完后执行
lsnrctl reload，不是stop/start——否则正在跑的连接会断
验证时别只看 lsnrctl status，要实际 telnet + sqlplus 测试
lsnrctl status 显示服务名在列表里，不代表它真能被 DGMGRL 用。因为 DGMGRL 默认走 SYSDBA 连接，而很多静态注册配置漏掉了 AS SYSDBA 权限所需的底层支持。
- 先
telnet确认端口通（排除防火墙、VIP 不通） - 再用
sqlplus /@STANDBY_DG as sysdba在主库上直连备库，看是否报ORA-12514；同样在备库上用sqlplus /@PRIMARY_DG as sysdba连主库 - 如果 sqlplus 成功但 DGMGRL 失败，检查
DGMGRL启动时用的是哪个ORACLE_HOME下的tnsnames.ora（它不读当前 shell 的 $TNS_ADMIN，只认自己的 $ORACLE_HOME/network/admin） - 特别注意 RAC 环境：DGMGRL 要求所有节点的静态注册只注册本地实例，
SID_NAME必须和该节点运行的实例名严格匹配，不能把 racnode2 的实例注册到 racnode1 的监听里
最容易被忽略的是：DGMGRL 连接依赖的是「监听器能立即响应 + 实例能被拉起」这两个硬条件，而不仅仅是“服务名存在”。静态注册漏掉 GLOBAL_DBNAME、tnsnames.ora 大小写不一致、或者用了 SCAN 代替 VIP，都会让整个 DG 切换链在第一步就卡死。
