Connection request timed out是连接池耗尽的明确信号，非网络或DB问题；需检查ActiveConnections是否逼近Max Pool Size、v$session会话数是否远低于池活跃数，并确保所有OracleConnection均用using正确释放。
Oracle.ManagedDataAccess.Client 连接超时问题，90% 不是网络或数据库本身慢，而是连接池耗尽或配置错位导致的假性超时。直接调大 Connect Timeout 或重试次数，往往掩盖了真实瓶颈。
Connection Request Timed Out 是连接池卡死，不是连不上库
错误信息 oracle.manageddataaccess.client.oracleexception: connection request timed out 表示：你的应用在等待从连接池获取一个可用连接，等了 15 秒（默认值）没等到，就抛异常了。
这不是数据库拒绝连接，而是 .NET 端连接池里没空闲连接可分——可能被长期占用、未释放，或池子太小扛不住并发。
- 检查
ActiveConnections监控指标是否持续逼近Max Pool Size（比如设了 50，监控常显示 48–50） - 对比数据库端
v$session中该应用的会话数（通常远小于连接池活跃数），若明显不匹配，说明连接没归还池子，大概率是using块漏写、异常绕过Dispose()、或手动调了Close()却没触发池回收 -
Connect Timeout=1这种极短设置反而加剧问题：它让每次建新物理连接失败更快，但无法缓解池子排队压力；应保持默认 15，优先解决池子健康度
Max Pool Size 和 Connection Lifetime 必须协同调优
单纯把 Max Pool Size 从 50 拉到 500，可能引发 Oracle 监听器拒绝连接（报 ORA-12519），因为数据库侧的 processes 限制没同步扩容。
- 先确认数据库允许的最大进程数：
SELECT value FROM v$parameter WHERE name = 'processes';，Max Pool Size建议 ≤ 该值的 70% -
Connection Lifetime设太长（如 300 秒）会导致连接长期滞留池中，即使后端连接已断开（如防火墙 kill 空闲连接），池子仍认为它“可用”，后续复用必失败；设为 60–120 秒较稳妥 - 避免同时设
Min Pool Size过高（如 20），冷启动时会一次性建满，加重 DB 负担且无实际收益
app.config / web.config 的 provider 注册必须版本严格一致
版本错位会导致连接根本构造不出来，表现就是首次 Open() 卡住几秒后抛“提供程序未注册”异常，继而触发超时重试逻辑，放大超时感知。
- 查 NuGet 引用的
Oracle.ManagedDataAccess版本号（如4.122.22.1），所有 config 文件中涉及的Version=必须一字不差 -
<section>和<provider>里的PublicKeyToken不能手输，从程序集属性复制，常见错是把89b483f429c47342写成89b483f429c47343 - 如果项目含 EF，
Oracle.ManagedDataAccess.EntityFramework的版本号需与主驱动匹配（如主驱动是 4.122.22.1，EF 包必须是 6.122.22.1）
IDLE_TIME 和 SQLNET.EXPIRE_TIME 是双保险，但生效层级不同
客户端连接空闲太久被 DB 主动断开，.NET 池子里的连接对象却不知情，下次复用就报 ORA-03135 或直接超时。得靠两端配合防僵死。
- 数据库侧设
IDLE_TIME（Profile 级）：对用户生效，单位分钟，例如ALTER PROFILE DEFAULT LIMIT IDLE_TIME 5;—— 5 分钟无操作就 kill 会话 - 网络层设
SQLNET.EXPIRE_TIME（sqlnet.ora）：对所有 TCP 连接发探测包，单位分钟，例如SQLNET.EXPIRE_TIME=3—— 每 3 分钟探一次，断连能更快被发现 - 二者不冲突，建议
SQLNET.EXPIRE_TIME比IDLE_TIME小 1–2 分钟，确保探测先于 DB 主动断连，让池子提前感知失效
v$session 对比，比盲目改 Max Pool Size 有效得多。 
