Oracle.ManagedDataAccess连接池默认开启且由连接字符串参数控制，关键参数包括Min/Max Pool Size、Incr/Decr Pool Size、Connection Lifetime等，需正确拼写并避免与EF Core双重池叠加导致连接泄漏。
Oracle.ManagedDataAccess 连接字符串里控制池行为
Oracle 官方 .NET 驱动 Oracle.ManagedDataAccess 的连接池是**内置且默认开启的**，不依赖外部池（如 Entity Framework Core 的连接池），所有池参数都通过连接字符串控制。你没法在代码里调 setMinPoolSize() 这类方法——那是 Java UCP 的玩法。
关键参数必须拼进 ConnectionString，例如：
data source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCLPDB1)));user id=myuser;password=mypass;Connection Timeout=30;Min Pool Size=5;Max Pool Size=50;Incr Pool Size=2;Decr Pool Size=1;Connection Lifetime=600;
-
Min Pool Size：启动即建的连接数，设太低会导致突发请求时创建连接卡顿；设太高则空闲连接占 PGA 内存（Oracle 每个会话固定消耗 ~5–10MB PGA） -
Max Pool Size：不是越大越好。9600 并发线程配 2048 连接反而让数据库 CPU 顶到 95%，实测降到 96 连接后 SQL 执行耗时从 77ms → 2ms -
Incr Pool Size和Decr Pool Size控制伸缩节奏，避免抖动；默认都是 1，高并发下可调为 2–5 -
Connection Lifetime（秒）：强制回收超时连接，防 Oracle 侧会话僵死；设 600（10 分钟）比永久存活更稳
EF Core 7 + Oracle.ManagedDataAccess 的双重池陷阱
EF Core 自带连接池（DbContext 级别），而 Oracle.ManagedDataAccess 又有一层物理连接池，两者叠加容易导致连接数翻倍、泄漏难定位、健康检查误报。
正确做法是关掉 EF Core 的连接复用逻辑，只信任底层 Oracle 池：
- 在
DbContext.OnConfiguring()中显式禁用 EF 的连接缓存：optionsBuilder.UseOracle(connectionString, o => o.DisableRetryOnFailure()) - 不要用
AddDbContextPool()，改用AddDbContext()，避免 EF 维护额外连接实例 - 确保每个
DbContext实例生命周期短（比如 scoped），用完即 dispose，否则 Oracle 连接不会归还到底层池
否则你会看到现象：监控显示 v$session 有 80 个活跃会话，但应用日志里只有 20 个请求正在执行——多出来的全是 EF 持有未释放的“幽灵连接”。
验证池是否真在起作用：查 v$session + 连接字符串日志
光看应用日志没用。Oracle 连接池是否生效，得直接查数据库端：
- 运行
SELECT username, status, schemaname, program FROM v$session WHERE program LIKE '%ODP.NET%';—— 正常应看到稳定在Min Pool Size到Max Pool Size之间的数量，而不是随请求飙升 - 在连接字符串里加
Trace Level=7;Trace File Location=C:\temp\，打开 ODP.NET 日志，搜索"Acquired connection"和"Released connection"，确认连接确实在复用而非反复新建 - 若日志里频繁出现
"Creating new connection"且无对应"Released"，说明应用层没正确 disposeOracleConnection或DbContext
注意：.NET 7 的 using 块必须包裹到最外层连接对象，不能只包 OracleCommand；漏掉 OracleConnection.Dispose() 就等于没还连接。
异步验证关不掉？那至少关掉同步校验
Oracle.ManagedDataAccess 没有 validateConnectionOnBorrow 这种开关，但它默认每次 Open() 都会执行一次轻量级验证（类似 SELECT 1 FROM DUAL）。在高频短请求场景下，这一步会成为瓶颈。
你无法完全跳过验证，但可以绕过它：
- 把连接字符串里的
Connection Timeout设为略大（如 30 秒），避免网络抖动触发重试放大延迟 - 启用
Self-Tuning：加参数Self Tuning=true;，驱动会自动根据响应时间动态调整验证频率 - 最关键的：确保 Oracle 监听器和网络稳定。一旦出现
ORA-12170: TNS:Connect timeout occurred，驱动会在后台反复重试，阻塞整个池
真正卡住吞吐量的，往往不是池大小，而是某次 DNS 解析失败或防火墙临时拦截后，几十个线程全堵在 Open() 上等超时——这种问题必须从网络层根治，不是调参能解决的。
