连接池溢出主因是配置与负载不匹配，常见于Pooling=false误配、MaxPoolSize过高或MinPoolSize失控；需用OracleConnectionStringBuilder显式设Pooling=true，并依据Oracle processes参数合理设置MaxPoolSize（如50~80）和MinPoolSize。
连接池溢出不是连接没关，而是连接池配置和实际负载严重不匹配。 你看到 ora-12519: tns:no appropriate service handler found 或应用日志里反复出现“无法获取连接”时，大概率是 maxpoolsize 设得太高、minpoolsize 没控住、或 pooling=false 被意外关闭导致连接不断新建又堆积。
确认 Pooling 是否真被启用
Oracle 官方驱动（System.Data.OracleClient）默认开启连接池，但这个行为极易被显式覆盖。检查你的连接字符串是否含 Pooling=false，哪怕只多一个空格或拼写错误（比如 pooling=fale），都会让整个池失效，变成每次 new OracleConnection() 都新建物理连接。
- 用
OracleConnectionStringBuilder构造连接串更安全：var builder = new OracleConnectionStringBuilder(connectionString); builder.Pooling = true; // 显式设为 true connectionString = builder.ConnectionString;
- 不要依赖“默认”，尤其在配置中心或环境变量注入场景下——任何中间环节都可能抹掉
Pooling键值对 - 验证方式：在连接打开后，立即查
connection.State是Open，再看connection.ConnectionString输出里是否含Polling=True（注意大小写不敏感，但值必须是True或Yes）
调整 MaxPoolSize 和 MinPoolSize 的真实依据
MaxPoolSize 不是越大越好，Oracle 数据库端有 processes 参数硬限制，超出就会拒绝新连接；MinPoolSize 设太高则空闲连接长期占着数据库资源，反而拖慢整体响应。
- 先查 Oracle 实例限制：
SELECT value FROM v$parameter WHERE name = 'processes';—— 假设返回300，那所有 .NET 应用的MaxPoolSize总和不能超过这个数（还要预留 DBA、监控等其他连接） - 生产环境单个服务建议
MaxPoolSize=50~80，除非压测证实并发请求持续 >100 且平均响应 -
MinPoolSize建议保持为0或1：冷启动时无需预热，连接池会按需增长；设成10意味着应用一启动就占 10 个 Oracle 进程，毫无必要 - 别信“核心数×2+磁盘数”这种通用公式——Oracle 的
processes是进程级限制，和 CPU 核心无关
Connection Timeout 和 Connection Lifetime 必须协同调优
连接池溢出常伴随大量“连接超时”，但根源往往不是网络慢，而是连接卡在池里出不去——因为旧连接没及时释放，新请求排队等不到空位。
-
Connection Timeout=30是合理的，但若数据库响应慢于 30 秒，连接会抛异常并从池中移除；此时要查 SQL 是否未加索引、锁等待是否过高，而非调大 timeout -
Connection Lifetime=0（默认）表示连接永不过期；高负载下建议设为300（5 分钟），强制连接定期重置，避免长连接积累状态泄漏（如游标未关闭、临时表残留） - Oracle 驱动不支持
LoadBalanceTimeout，该参数在 SQL Server 字符串里有效，但在 Oracle 连接串中会被忽略——别白加
真正棘手的是连接泄漏：OracleConnection 对象没走 using 或没调 Close()，连接就不会归还池中。这类问题不会立刻报错，但几小时后池就满了。用 Oracle 自带的 v$session 视图查 STATUS='INACTIVE' 且 LOGON_TIME 超过 1 小时的会话，基本就是泄漏点。
