Min Pool Size 和 Max Pool Size 必须显式设置，建议设为5～10和合理上限值；Connection Lifetime 应设为600秒并启用 Validate Connection=true；Decr Pool Size 提高至5～10；统一用 OracleConnectionStringBuilder 构造连接串。
Min Pool Size 和 Max Pool Size 必须显式设置
ODP.NET 默认 Min Pool Size=1、Max Pool Size=100，但这两个值在生产环境几乎总是错的。不显式声明会导致连接池在低峰期清空所有空闲连接，高峰期又得重建物理连接——Oracle 的连接建立成本远高于 MySQL，一次完整握手加认证常超 300ms，直接拖垮响应时间。
实操建议：
-
Min Pool Size应设为服务实例预期内的稳定并发基线（比如 5～10），确保冷启动后有足够连接可立即复用 -
Max Pool Size要结合数据库processes参数和实例数反推：单实例最大可用连接 ≈(DB_processes - reserved)÷ 实例数；常见误配是把每个实例都设成 100，8 个实例就占掉 800 连接，远超 Oracle 的 455 session 上限 - 连接字符串中必须写成
Min Pool Size=5;Max Pool Size=20;（等号前后无空格），否则因字面量不一致触发池分裂，死连接被隔离无法回收
Connection Lifetime=0 是陷阱，别信
Connection Lifetime=0 只是禁用连接池主动销毁逻辑，但 Oracle 服务端仍会因 IDLE_TIME、RAC 切换、网络中断或数据库重启，把连接标记为 SNIPED。.NET 连接池对此毫无感知，下次取出就直接抛 ORA-03135 或 ORA-01041。
实操建议：
- 设
Connection Lifetime=600（10 分钟），让连接定期“自然退役”，避免长期存活导致 TCP 僵死 - 搭配
Validate Connection=true，每次Open()前执行SELECT 1 FROM DUAL校验，代价小但能拦截 SNIPED 连接 - 注意：
Validate Connection=true仅在高复用率、网络不稳定或 DBA 配了严格IDLE_TIME的场景启用，否则纯属增加无效 round-trip
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，形成“定时刷新 + 即时校验 + 快速清理”三层防线 - 别指望
using块或 GC 解决问题——死连接卡在池与数据库之间的状态同步层，应用层根本看不见
用 OracleConnectionStringBuilder 构造连接串更安全
手拼连接字符串极易出错：大小写、空格、分号位置、参数顺序稍有差异，ODP.NET 就认为是全新连接池。比如 Min Pool Size = 5（等号带空格）和 Min Pool Size=5 会被当成两个池，旧池里的死连接永远无法被新请求复用。
实操建议：
- 强制使用
OracleConnectionStringBuilder，它会自动标准化键名、去除冗余空格、统一大小写 - 若需动态拼接用户名/密码，务必先
.Trim()再.ToLower()，再塞进 builder - 连接字符串应集中管理，禁止硬编码在多个
appsettings.json或代码里，避免配置漂移
真实线上故障往往不是某一个参数错了，而是几个默认值叠加放大：没设 Min Pool Size 导致冷启慢，Connection Lifetime=0 让死连接越积越多，Decr Pool Size=1 又让它赖着不走——最后一起爆发。调优不是调单点，是让这几个参数彼此咬合、互相兜底。
