ORA-12514在Data Guard中主因是备库监听器未识别DG服务名，需用lsnrctl status确认是否显示orcl_stby等专用服务名；若缺失，则检查listener.ora中SID_LIST_LISTENER静态注册的GLOBAL_DBNAME是否与客户端连接串SERVICE_NAME完全一致（含大小写），且SID_NAME、ORACLE_HOME配置正确，修改后执行lsnrctl reload生效。
确认备库监听器是否识别了DG服务名
ora-12514在data guard环境中出现，往往不是因为主库连不上，而是备库监听器压根没“认出”你请求的service_name——尤其是那个用于日志传输或broker管理的专用服务（如orcl_stby或orcldg）。先别急着改配置，用lsnrctl status看输出里有没有你期望的服务名条目。如果只看到orcl或orclxdb，但没有备库角色相关的服务，说明监听器根本没加载它。
检查listener.ora中是否配置了静态服务条目
Oracle 19c DG环境默认依赖动态注册，但备库处于MOUNT状态时，service_names参数不会生效，也无法向监听器注册服务——这时必须靠listener.ora里的静态SID_LIST兜底。常见遗漏点：
- 没加
SID_DESC块，或加了但GLOBAL_DBNAME写成了主库服务名（比如写了orcl而不是orcl_stby） -
SID_NAME填的是实例名（如orcl），但GLOBAL_DBNAME没同步更新为备库服务名 -
ORACLE_HOME路径错误，导致监听器启动时跳过该条目（lsnrctl status输出里会提示“Unknown SID”）
正确示例（备库专用）：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = orcl_stby)
(ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1)
(SID_NAME = orcl)
)
)
验证tnsnames.ora中DG连接串是否匹配静态服务名
主库的LOG_ARCHIVE_DEST_2或DGMGRL的ADD DATABASE命令里写的TNS别名，必须和备库tnsnames.ora中定义的服务名一致，且该服务名要能解析到备库监听器+端口，并请求正确的SERVICE_NAME。
容易踩的坑：
- 主库tnsnames.ora里写的是
(SERVICE_NAME = orcl)，但备库监听器只静态注册了orcl_stby - 用了Easy Connect语法（如
stby-host:1521/orcl_stby），但备库监听器未启用USE_SID_AS_SERVICE_LISTENER参数，仍要求严格匹配GLOBAL_DBNAME -
tnsnames.ora放在了错误位置（比如Instant Client下却没设TNS_ADMIN），导致主库实际读取的是空配置
重启监听器后仍不生效？检查日志和注册状态
改完listener.ora必须执行lsnrctl reload或lsnrctl stop && lsnrctl start，否则配置不加载。但更关键的是看监听日志（$ORACLE_HOME/network/log/listener.log）里有没有类似这样的行：
TNS-12502: TNS:listener received no CONNECT_DATA from client
或者更直接的线索：
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=stby-host)(PORT=1521))) Services Summary... Service "orcl_stby" has 1 instance(s). Instance "orcl", status UNKNOWN, has 1 handler(s) for this service...
注意：状态是UNKNOWN才对——这是静态注册的标志；如果是READY，说明走的是动态注册（备库MOUNT状态下不可能出现）。
真正容易被忽略的是：静态注册的GLOBAL_DBNAME必须和客户端连接串里请求的SERVICE_NAME完全一致（包括大小写），哪怕只差一个下划线，监听器就直接返回ORA-12514，连日志都懒得记。
