ODP.NET连接池默认启用，但Max Pool Size超Oracle PROCESSES限制或Connection Lifetime≠0会导致连接不复用、ORA-12519报错；连接字符串须逐字符一致，Min Pool Size不维持常驻连接。
odp.net连接池在asp.net core中默认启用，但max pool size和connection lifetime设错或冲突，会导致连接不复用、频繁新建物理连接、甚至ora-12519报错——这不是池没开，而是参数在“悄悄失效”。
Max Pool Size不是越大越好，超了Oracle服务端PROCESSES就卡死
Oracle数据库的PROCESSES参数硬性限制了最大并发会话数（含后台进程），而每个ODP.NET物理连接至少占用1个process。若应用设Max Pool Size=200，但数据库只配了PROCESSES=150，实际可用连接顶多120–130个（留出后台进程余量）。
- 查当前限制：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'processes'; - 安全上限建议：把
Max Pool Size设为PROCESSES × 0.7（例如150 → 100） - 避免和EF Core的
MaxDegreeOfParallelism叠加误判：后者控制查询并发度，不等于连接数 - 别在
appsettings.json里写"Max Pool Size": 100——JSON解析后变成整数，ODP.NET只认字符串形式的连接字符串参数
Connection Lifetime=0才是生产环境的合理默认值
设Connection Lifetime=60看似“防长连接老化”，实则让每个连接在取出后存活满60秒就标记为过期；归还时直接关闭，不进池——等于废掉了连接复用能力。尤其在低频请求场景下，几乎每次都是新连。
-
Connection Lifetime=0表示禁用基于时间的销毁逻辑（推荐生产环境固定使用） - 真正需要控制生命周期的场景极少，比如连接串含动态密码且需强制轮换，才考虑非零值
- 注意它和
Connection Timeout无关：Connection Timeout=30只影响Open()建连阶段，不干预池内复用 - 若你启用了Oracle RAC，
Connection Lifetime还可能干扰FAN事件感知，进一步降低故障转移效率
连接字符串字面量必须完全一致，空格/大小写/顺序都算不同池
ODP.NET判断是否可复用连接，靠的是连接字符串的**逐字符比对**。哪怕两处代码都写"Min Pool Size=5"，一处多一个空格、一处用小写min pool size，就会分裂成两个独立池——资源被割裂，利用率暴跌。
- 统一用标准拼写：
Min Pool Size=5; Max Pool Size=100; Connection Lifetime=0; Pooling=true; - 等号前后严禁空格（
Min Pool Size = 5会被忽略） - 避免在代码中拼接连接字符串，尤其是用户名/密码字段——哪怕值相同，拼接过程引入不可见字符也会导致池分裂
- 检查日志里是否出现多个
OracleConnection实例指向同一数据库但不同池名，这是分裂的明确信号
最常被忽略的一点：ODP.NET的Min Pool Size只影响首次启动时的预热，不维持常驻连接。如果业务有明显波峰波谷，空闲连接仍会因Inactive Connection Timeout（默认10分钟）被回收——这跟Min Pool Size设多少无关，得靠监控活跃连接曲线来确认真实水位，而不是看配置数字。
