Oracle RAC连接必须配置TNS_ADMIN环境变量指向tnsnames.ora目录，且tns别名中须用ADDRESS_LIST包裹多个ADDRESS实现多节点轮询；.NET需启用HA Events=true并调优连接池（如Connection Lifetime=0）以支持FAN事件驱动的故障转移。
Oracle RAC 连接字符串里必须带 TNS_ADMIN 和 ADDRESS_LIST
不配 TNS_ADMIN，.NET 程序根本找不到 tnsnames.ora；没用 ADDRESS_LIST（或等价的 DESCRIPTION_LIST），Oracle 客户端压根不会尝试多节点轮询。常见错误是直接写单个 HOST + PORT，这等于把 RAC 当单实例用，故障时完全不切换。
实操建议：
-
TNS_ADMIN环境变量需在应用启动前设置，指向包含tnsnames.ora的目录（如C:\oracle\network\admin），不能只靠 Oracle 安装默认路径 -
tnsnames.ora中对应别名必须使用ADDRESS_LIST包裹多个ADDRESS，且每个ADDRESS含独立(HOST=...)(PORT=...)(PROTOCOL=TCP) - 启用连接时重试：在连接字符串加
Connect Timeout=15;Connection Lifetime=0;Incr Pool Size=1;Decr Pool Size=1;，避免连接池缓存失效地址
Oracle.ManagedDataAccess 要开 HA Events 才能触发自动故障转移
默认情况下，即使 TNS 配置正确，Managed Driver 也不会监听 Oracle RAC 的 FAN（Fast Application Notification）事件，也就无法在节点宕机后主动剔除坏连接、重路由新请求。关掉这个开关，所谓“自动切换”只是靠连接失败后的重试，延迟高、不可控。
实操建议：
- 连接字符串中必须显式添加
HA Events=true - 确保数据库端已启用 FAN：DBA 需执行
exec DBMS_SERVICE.MODIFY_SERVICE(service_name => 'your_svc', aq_ha_notifications => TRUE); - 应用进程需有权限订阅 FAN 通知——通常要求连接用户被授予
EM_EXPRESS_BASIC角色或等效权限
连接池行为必须调优，否则切换后旧连接仍可能复用
.NET 默认连接池会缓存连接对象，哪怕底层 TCP 已断开、RAC 节点已切换，池中“活着”的连接句柄仍可能被分配出去，导致 ORA-03113: end-of-file on communication channel 或超时。
实操建议：
- 设
Connection Lifetime=0强制每次取连接都验证有效性（代价是轻微性能损耗，但换来可靠性） - 禁用连接池可临时验证问题：
Pooling=false，若此时切换正常，说明问题出在池策略上 - 配合
Validate Connection=true，让驱动在返回连接前执行SELECT 1 FROM DUAL检测连通性（注意增加网络往返）
别忽略 Oracle 客户端版本和 .NET 运行时兼容性
Oracle.ManagedDataAccess 21.x 在 .NET 6+ 上表现稳定，但若混用旧版（如 19c client + .NET Core 3.1），可能出现 FAN 事件解析失败、ADDRESS_LIST 解析跳过次节点等问题，错误日志里往往只报泛泛的 ORA-12154 或静默连接到第一个节点不切换。
实操建议：
- 统一使用
Oracle.ManagedDataAccess≥ 23.4（2023 年后发布），它对 RAC 23c/19c 的 FAN 和 SCAN 支持最完整 - 避免混合部署：不要在一个进程里同时引用
Oracle.DataAccess（ODP.NET Unmanaged）和Oracle.ManagedDataAccess - 启用驱动诊断日志：
Trace Option=1;Trace File Location=C:\temp\oda_trace.log，重点查FAN event received和failover started日志行
真正起作用的不是“配置一堆参数”，而是 TNS 层真实解析出多个地址、驱动层收到 FAN 通知、连接池不兜底旧连接——三者缺一不可。最容易被跳过的其实是数据库端的 FAN 开关和服务注册状态，光调客户端没用。
