Oracle.ManagedDataAccess默认不读tnsnames.ora，必须显式设置OracleConfiguration.TnsAdmin路径或使用完整连接字符串；tnsping成功但.NET连不上是因两者环境隔离，TNS_ADMIN环境变量对其无效。
Oracle.ManagedDataAccess 默认不读 tnsnames.ora，除非你显式指定 TnsAdmin 路径。
为什么 tnsping 成功但 .NET 应用连不上
这是最典型的错觉：你在命令行跑 tnsping MYDB 返回 OK，但 OracleConnection.Open() 仍抛 ORA-12154。根本原因不是配置错，而是客户端环境不一致。
-
tnsping用的是系统级 Oracle Client（受TNS_ADMIN、ORACLE_HOME环境变量影响） - .NET 的
Oracle.ManagedDataAccess（推荐用的纯托管驱动）默认完全忽略这些环境变量，也不自动查找tnsnames.ora - 它只在两种情况下才读该文件：① 你代码里调用
OracleConfiguration.TnsAdmin = @"C:\path\to\admin"；② 连接字符串里写的是别名（如MYDB），且已设置TnsAdmin
Data Source 写法决定是否依赖 tnsnames.ora
连接字符串格式直接决定解析路径：
- 用别名（如
Data Source=MYDB;）→ 必须配OracleConfiguration.TnsAdmin，否则直接报ORA-12154 - 用完整描述符（如
Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=db.example.com)(PORT=1522))(CONNECT_DATA=(SERVICE_NAME=orclpdb1)));）→ 完全绕过tnsnames.ora，最可靠 - 用简写格式（如
Data Source=db.example.com:1522/orclpdb1;）→ 仅适用于基本场景，不支持负载均衡、故障转移等高级特性
Windows 上 TNS_ADMIN 环境变量对 .NET 应用无效
哪怕你全局设置了 TNS_ADMIN，Oracle.ManagedDataAccess 也不会读它 —— 这是设计使然，不是 bug。
- 不要指望注册表或系统环境变量能“自动生效”
- 如果坚持用别名方式，必须在应用启动早期（比如
Program.cs或Global.asax）执行：OracleConfiguration.TnsAdmin = @"C:\oracle\network\admin"; - 路径必须精确到目录，不能带
tnsnames.ora文件名；该目录下必须有可读的tnsnames.ora，且语法无空格、括号闭合、换行正确 - 若部署在 IIS，注意应用池 Identity 对该目录是否有读权限（常被忽略）
最容易被忽略的 SERVICE_NAME 大小写与多租户匹配
即使路径、语法、连接字符串全对，ORA-12154 仍可能来自一个极隐蔽的点：PDB 名和 SERVICE_NAME 不一致。
- Oracle 12c+ 默认为每个 PDB 创建同名 service，但实际注册到监听器的 service 名是小写的（如
orclpdb1），而很多人习惯写大写ORCLPDB1 - 用
lsnrctl status查看输出里的Service "orclpdb1" has 1 instance(s)，那个引号里的值才是真实 service 名 -
tnsnames.ora中的(SERVICE_NAME = orclpdb1)必须严格匹配，包括大小写 - Java/.NET 都区分这个大小写，但 sqlplus 有时会“宽容”——这进一步掩盖问题
