Connection request timed out 实质是连接池耗尽而非网络不通，因 OracleConnection 未显式释放导致池满，新请求在 Open() 处等待超时；ODP.NET 严格按连接字符串逐字符匹配分池，空格、大小写等差异会分裂池；Connection Lifetime=60 废弃复用，应设为0。
Connection request timed out 其实是“拿不到连接”，不是“连不上”
这个错误出现时，应用日志里常看到 connection request timed out，但数据库本身能连、tnsping通、sqlplus也能登录——说明网络和监听器都没问题。真实原因是：连接池已满，所有 oracleconnection 都被占着没归还，新请求在 open() 调用处无限等待，直到超时才抛异常。
典型现象包括：
-
v$session中大量STATUS = 'INACTIVE'，且LAST_CALL_ET > 1800 - Windows 性能计数器中
NumberOfFreeConnections长期为 0，NumberOfActiveConnections卡在Max Pool Size值附近 - 重启应用后立刻恢复，几小时内复现
90% 的泄漏来自 OracleDataReader 没关、using 提前跳出、catch 里吞异常
连接不会自动归还池，必须显式释放。ODP.NET 不靠 GC 回收连接，只认 Dispose() 或 Close()。
常见泄漏点：
-
OracleCommand.ExecuteReader()后没调reader.Close()或没包在using里 -
using (var conn = new OracleConnection(cs)) { ... if (x) return; }—— 提前 return，conn不会 Dispose -
try { cmd.ExecuteNonQuery(); } catch (Exception e) { log.Error(e); return; }—— 异常路径没释放连接 - 把
OracleConnection存在类字段或静态变量里，长期持有不释放
连接字符串差一个空格，就分裂成两个独立池
ODP.NET 判断池是否可复用，靠的是连接字符串**逐字符比对**。大小写、空格、分号位置、甚至换行符不同，都会创建新池。
后果很直接：
- 本该共用 100 个连接的场景，变成两个池各占 50，但每个池都卡在
Max Pool Size=100的上限上 - 监控看到
NumberOfActiveConnections加起来是 200，但单个池里NumberOfFreeConnections还是 0 - 日志里出现多个
OracleConnection实例指向同一数据库，却显示不同池名（如pool-1和pool-2）
实操建议：
- 禁止在代码里拼接连接字符串，尤其避免
string.Format或$"Data Source={host}..." - 等号前后不能有空格：
Max Pool Size=100✅，Max Pool Size = 100❌（会被忽略） - 统一用小写参数名，服务名全大写或全小写保持一致
Connection Lifetime=60 是性能杀手，不是保命符
设 Connection Lifetime=60 看似“防连接老化”，实际让每个从池取出的连接，只要存活满 60 秒就标记过期；归还时直接关闭，不进池——等于废掉了复用能力。
尤其在低频请求或长周期任务中，几乎每次都是新建物理连接，完全抵消了连接池价值。
真正该设的值是：
-
Connection Lifetime=0（推荐生产环境固定使用）：禁用基于时间的销毁逻辑 - 仅当需配合动态密码轮换等极少数场景，才考虑非零值
-
Connection Timeout=15才控制“等连接”的最大等待时间，和 Lifetime 无关
另外注意：Validate Connection=true 每次取连接都执行 SELECT 1 FROM DUAL，增加 1–2ms 往返开销，高频场景下建议关掉。
