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环境中出现，往往不是因为主库连不上，而是备库监听器压根没“认出”你请求的
——尤其是那个用于日志传输或broker管理的专用服务（如
或
）。先别急着改配置，用
看输出里有没有你期望的服务名条目。如果只看到
或
，但没有备库角色相关的服务，说明监听器根本没加载它。
检查listener.ora中是否配置了静态服务条目
Oracle 19c DG环境默认依赖动态注册，但备库处于MOUNT状态时，
参数不会生效，也无法向监听器注册服务——这时必须靠
里的静态
兜底。常见遗漏点：
没加
块，或加了但
写成了主库服务名（比如写了
而不是
）
填的是实例名（如
），但
没同步更新为备库服务名
路径错误，导致监听器启动时跳过该条目（
输出里会提示“Unknown SID”）
正确示例（备库专用）：
验证tnsnames.ora中DG连接串是否匹配静态服务名
主库的
或DGMGRL的
命令里写的TNS别名，必须和备库
中定义的服务名一致，且该服务名要能解析到备库监听器+端口，并请求正确的
。
容易踩的坑：
主库tnsnames.ora里写的是
，但备库监听器只静态注册了
用了Easy Connect语法（如
），但备库监听器未启用
参数，仍要求严格匹配
放在了错误位置（比如Instant Client下却没设
），导致主库实际读取的是空配置
重启监听器后仍不生效？检查日志和注册状态
改完
必须执行
或
，否则配置不加载。但更关键的是看监听日志（
）里有没有类似这样的行：
或者更直接的线索：
注意：状态是
才对——这是静态注册的标志；如果是
，说明走的是动态注册（备库MOUNT状态下不可能出现）。
真正容易被忽略的是：静态注册的
必须和客户端连接串里请求的
完全一致（包括大小写），哪怕只差一个下划线，监听器就直接返回ORA-12514，连日志都懒得记。
service_nameorcl_stbyorcldglsnrctl statusorclorclxdbservice_nameslistener.oraSID_LISTSID_DESCGLOBAL_DBNAMEorclorcl_stbySID_NAMEorclGLOBAL_DBNAMEORACLE_HOMElsnrctl status
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = orcl_stby)
(ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1)
(SID_NAME = orcl)
)
)
LOG_ARCHIVE_DEST_2ADD DATABASEtnsnames.oraSERVICE_NAME(SERVICE_NAME = orcl)orcl_stbystby-host:1521/orcl_stbyUSE_SID_AS_SERVICE_LISTENERGLOBAL_DBNAMEtnsnames.oraTNS_ADMINlistener.oralsnrctl reloadlsnrctl 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...
UNKNOWNREADYGLOBAL_DBNAMESERVICE_NAME