Data Guard必须用静态监听，因为备库MOUNT状态下PMON无法动态注册服务，导致DG同步、Broker连接及DGMGRL操作依赖的监听服务不可见，易引发ORA-16625等错误；需确保GLOBAL_DBNAME（如db_unique_name_DGMGRL）、SID_NAME（实例名）和ORACLE_HOME三者严格对齐并 reload 生效。
为什么Data Guard必须用静态监听
因为备库启动到 MOUNT 状态时，PMON 无法向监听器动态注册服务；而 DG 同步、Broker 连接、DGMGRL 操作都依赖监听能“看到”这个实例。动态监听下状态会是 UNKNOWN 或直接不显示，导致连接失败或 Broker 报错 ORA-16625: cannot reach database。
SID_LIST_LISTENER 配置要点
关键不是加几行，而是三项必须对齐：
-
GLOBAL_DBNAME：对外暴露的服务名，DG Broker 要求为<db_unique_name>_DGMGRL（如主库db12g_dgmgrl，备库db12g_s_dgmgrl） -
SID_NAME：实际运行的实例名（instance_name），不是db_name或service_name -
ORACLE_HOME：必须精确指向当前数据库软件安装路径，不能写软链路径或环境变量名
示例（主库）：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = db12g_dgmgrl)
(ORACLE_HOME = /u01/app/oracle/product/12.2.0/db_1)
(SID_NAME = db12g)
)
)
监听 reload 后验证状态是否生效
执行 lsnrctl reload 后，立刻用 lsnrctl status 查看：
- 服务名应出现在
Services Summary中，且对应实例状态为UNKNOWN（这是静态监听的正常标志） - 若仍看不到该服务，检查
listener.ora是否有语法错误（括号配对、空格、换行） - 确认监听进程是否真正读取了修改后的文件：
lsnrctl show current_listener和lsnrctl show parameter file可验证加载路径 - Linux 下注意 SELinux 或防火墙可能拦截 IPC 地址（
KEY=EXTPROC1521），临时关闭测试可排除干扰
主备库监听配置常见错位点
最容易被忽略的是角色错配和端口不一致：
- 主库和备库的
listener.ora必须各自独立配置 —— 备库的GLOBAL_DBNAME必须是它自己的db_unique_name_DGMGRL，不能照抄主库 - TNS 名称（
tnsnames.ora）中指向备库的条目，其HANDLER地址必须与备库监听的HOST和PORT完全一致（比如主库监听192.168.10.51:1521，备库条目就不能写成localhost） - 如果主备监听端口不同（例如主库用 1521、备库用 1522），
tnsnames.ora中对应条目的PORT值必须同步改掉，否则DGMGRL连接会超时
静态监听本身不复杂，但一旦错一个字母或漏一个括号，lsnrctl 不报错，status 却不显示服务 —— 这种静默失效最耗排查时间。
