ORA-12514 根本原因是连接字符串中的 SERVICE_NAME 与监听器注册的服务名不一致，需通过 show parameter service_names 和 lsnrctl status 精确比对大小写、域名等完整值。
ora-12514 不是 .net 的锅，而是连接字符串里的 service_name 和监听器注册的服务名对不上。 你用的是 oracle.manageddataaccess 还是 system.data.oracleclient（已弃用）都不影响这个错误的本质——监听器查表时没找到你写的那个名字。
检查数据库实际注册的 SERVICE_NAME 是什么
别信配置文档或旧笔记，直接问数据库自己：
- 连上数据库：
sqlplus / as sysdba - 执行：
show parameter service_names;—— 注意是复数service_names，不是service_name - 再确认实例状态：
select instance_name, status from v$instance;（确保status是OPEN）
输出类似：service_names = prod_app,prod_app.us.example.com。你必须从这里面挑一个完整、准确的值（包括大小写和域名），填进 .NET 连接字符串的 SERVICE_NAME 部分。
.NET 连接字符串里 SERVICE_NAME 必须和 lsnrctl status 输出完全一致
运行 lsnrctl status，在 Services Summary 区域找你期望的服务名。比如：
Service "prod_app.us.example.com" has 1 instance(s).
如果这里显示的是 prod_app.us.example.com，但你的 .NET 连接字符串写的是 prod_app 或 PROD_APP，就会报 ORA-12514。
- 大小写敏感：Oracle 默认区分大小写，
Prod_App≠prod_app - 域名部分不能省：如果
lsnrctl status显示带.us.example.com，连接字符串里也得带上 - 不要混用 SID：
SID=ORCL和SERVICE_NAME=ORCL在 12c+ 多租户环境下通常不等价
常见踩坑点：tnsnames.ora 没生效，.NET 却在读它
很多 .NET 应用（尤其用 Oracle.ManagedDataAccess）默认走 EZCONNECT，但一旦你设置了环境变量 TNS_ADMIN 或应用里显式指定 Data Source=(DESCRIPTION=...)，就会触发 TNSNAMES 解析。
- 检查
TNS_ADMIN环境变量是否指向了错误的目录（比如旧 Oracle Home 下的tnsnames.ora） - 用
tnsping your_service_name测试：如果返回OK (n msec)且显示的地址和端口是你预期的，说明解析成功；否则就是tnsnames.ora路径或内容错了 - 连接字符串中若含
(DESCRIPTION=...片段，优先级高于TNS_ADMIN，此时tnsnames.ora完全不参与解析
动态注册延迟导致短暂 ORA-12514，别急着重启
数据库刚启动后，PMON 进程默认每 60 秒向监听器注册一次。这期间 lsnrctl status 可能查不到服务，.NET 就会报 ORA-12514。
- 不用重启监听器或数据库，等 1–2 分钟再试
- 手动触发注册：
alter system register;（需 DBA 权限） - 如果频繁遇到，检查
local_listener参数是否指向正确的监听地址（HOST不能是localhost，而应是监听器实际绑定的 IP）
真正难排查的，往往不是配置写错，而是 service_names 值本身被多个参数（db_name、db_domain、PDB 名称）动态拼接出来，又没及时同步到监听器。每次改完参数，记得跑一遍 lsnrctl status 对照看。
