Connection Lifetime=0 不等于连接永不过期，它仅关闭主动销毁机制，但 Oracle 服务端仍会因网络中断、RAC 切换、重启或 IDLE_TIME 而强制终止连接，导致 .NET 连接池无法感知并抛出 ORA-03135 或 ORA-01041。
Connection Lifetime=0 不等于连接永不过期
很多人以为设 connection lifetime=0 就能让连接一直复用，其实它只是关闭了“按存活时间主动销毁”的机制，但 oracle 服务端仍会因网络中断、rac 节点切换、数据库重启或 idle_time 配置而把连接标记为 sniped（强制终止）。此时 .net 连接池并不知情，下次取出该连接时直接抛 ora-03135 或 ora-01041。
实操建议：
- 显式设
Connection Lifetime=600（10 分钟），让连接池定期刷新，避免陈旧连接堆积 - 搭配
Validate Connection=true，每次从池中取出前执行轻量验证（SELECT 1 FROM DUAL），代价小但能拦截 SNIPED 连接 - 注意：仅在连接复用率高、网络不稳定或 DBA 设置了严格
IDLE_TIME的场景启用Validate Connection，否则纯属冗余开销
连接字符串不一致导致池分裂，死连接被隔离在错误池里
ODP.NET 判断连接是否可复用，依赖连接字符串的**字面量完全一致**——包括空格、分号位置、大小写、参数顺序。哪怕只多一个空格（如 Min Pool Size = 5 中等号前后有空格），就会创建新池，旧池里的死连接无法被新请求复用，也无法被统一回收。
实操建议：
- 连接字符串中必须用标准格式：
Min Pool Size=5; Max Pool Size=100;（等号前后无空格） - 避免动态拼接用户名/密码；若必须拼接，统一 trim + toLower 处理后再构建
- 用
OracleConnectionStringBuilder构造连接串，它会自动标准化键名和格式，规避手拼风险
Decr Pool Size=1 导致死连接长期滞留
连接池空闲连接回收靠 Decr Pool Size 控制，默认值是 1，意味着每 3 秒只关闭 1 个空闲连接。高峰期过后，大量连接处于 idle 状态却迟迟不释放，既占着 Oracle processes 资源，又可能在数据库端已被 SNIPED，变成“假活跃真失效”的死连接。
实操建议：
- 将
Decr Pool Size提高到 5～10，加快空闲连接回收节奏 - 配合
Connection Lifetime=600和Validate Connection=true，形成“定时刷新 + 即时校验 + 快速清理”三层防线 - 不要指望 GC 或
using块能解决这个问题——死连接不在应用层，而在池与数据库之间那层看不见的状态同步里
Validate Connection=true 的真实代价和适用边界
Validate Connection=true 看似万能，但它会在每次 Open() 前额外发一次 SQL 查询。在 QPS 超过 500 的服务上，这可能带来可观延迟，尤其当数据库响应慢或网络抖动时，反而放大超时风险。
实操建议：
- 只在以下情况启用：
IDLE_TIME≤ 10 分钟、跨机房部署、RAC 环境、或历史日志频繁出现ORA-03135 - 禁用时，务必确保
Connection Lifetime不为 0，且值略小于数据库IDLE_TIME（例如 DB 设了 900 秒，这里设 840） - 永远不要把它当成“兜底开关”——它治标不治本，真正要控的是连接生命周期与数据库策略的对齐
processes 和 IDLE_TIME、以及应用实际流量波峰波谷的节奏。漏掉任何一环，死连接都会悄悄回来。 
