DGMGRL远程重启必须用静态监听，因为数据库未启动时动态注册不可用，静态注册通过listener.ora中GLOBAL_DBNAME、SID_NAME、ORACLE_HOME三项显式配置，使监听器能在实例关闭状态下响应SYSDBA连接请求，确保START DATABASE或REINSTATE成功。
为什么DGMGRL远程重启必须用静态监听
DGMGRL执行 START DATABASE 或 REINSTATE 时，会尝试通过监听器发起 SYSDBA 连接来拉起实例——此时数据库很可能还没启动，动态注册根本不存在。LREG 进程只在实例运行后才工作，而静态注册让监听器“提前知道”该服务名对应哪个 SID_NAME 和 ORACLE_HOME，哪怕实例是关闭状态也能响应连接请求。
常见错误现象包括：ORA-12514: TNS:listener does not currently know of service requested in connect descriptor，或 DGMGRL 报错 “Failed to start instance”，但 lsnrctl status 显示服务名在列表里（其实是动态注册的 READY 状态，但实例未启）。
listener.ora 中必须写的三项静态注册参数
每个节点的 listener.ora 必须包含完整、显式的 SID_DESC，漏掉任意一项都会导致 DGMGRL 连接失败：
-
GLOBAL_DBNAME必须等于你准备在tnsnames.ora中使用的SERVICE_NAME，且大小写完全一致（例如PRIMARY_DG≠primary_dg） -
SID_NAME必须等于本机实际的ORACLE_SID（RAC 中是单实例名，如orcl1，不是 DB_UNIQUE_NAME） -
ORACLE_HOME必须是绝对路径，不能含环境变量（如$ORACLE_HOME无效），也不能拼错（比如/u01/app/oracle/product/19c/dbhome_1少个_就失败）
示例（备库上为连回主库而配）：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = PRIMARY_DG)
(ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1)
(SID_NAME = orcl1)
)
)
tnsnames.ora 双向配置和 VIP 使用要点
DGMGRL 在 switchover/reinstate 过程中，始终使用**本地**的 tnsnames.ora 解析目标库地址。这意味着主库和备库都必须能互相解析对方的服务名——不是单向，是双向。
- 主库的
tnsnames.ora中要有指向备库的条目，SERVICE_NAME值必须与备库 listener.ora 中的GLOBAL_DBNAME完全一致 - 备库同理，必须有指向主库的条目，
SERVICE_NAME也必须匹配主库 listener.ora 的GLOBAL_DBNAME - RAC 环境下，
HOST必须填对方的 VIP（如192.168.100.11），绝不能填 SCAN 或主机名——SCAN 不支持静态注册的GLOBAL_DBNAME匹配 - 端口统一：两边都用 1521，或都用自定义端口（如 1525），混用会导致连接超时或 ORA-12170
验证静态注册是否真正生效
lsnrctl status 显示服务名只是第一步，关键要看它是不是静态注册的，并且能否被 DGMGRL 实际调用：
- 执行
lsnrctl status，找到对应服务名，确认其状态是UNKNOWN（不是READY）——只有UNKNOWN才表示静态注册成功 - 用
telnet vip_address port测试监听端口通不通（排除防火墙/网络问题） - 用
sqlplus /@service_name as sysdba本地测试（注意：必须带as sysdba，因为 DGMGRL 默认走这个权限路径） - 最后用 DGMGRL 连上后执行
SHOW CONFIGURATION，再手动关掉目标库实例，尝试START DATABASE——这才是最终验证
最容易被忽略的是：改完 listener.ora 后必须执行 lsnrctl reload，而不是 stop/start；reload 不中断现有连接，且能立即加载新配置。如果用了 stop/start，旧连接全断，而且可能因顺序问题导致监听无法绑定端口。
