Connection request timed out 是连接池耗尽导致新请求在 Open() 处等待超时，非网络问题；BadImageFormatException 是 .NET 进程位数与 Oracle Instant Client 本机 DLL 架构不匹配所致；ORA-12514 是监听器未注册所连 SERVICE_NAME，非服务端宕机。
Connection request timed out 不是网络问题，而是连接池被占满后新请求在 Open() 处卡住等待；BadImageFormatException 不是 Oracle 配置错，而是 .NET 进程位数和 Instant Client 本机 DLL 架构不匹配；ORA-12514 不是服务端挂了，是监听器根本不认识你写的 SERVICE_NAME。这些“未处理异常”背后，90% 都不是意外，而是可预见、可拦截、可修复的资源管理或配置偏差。
为什么 Connection request timed out 总在下午/晚上爆发
这不是偶发超时，是连接泄漏累积到临界点后的必然结果。池里所有连接都被 OracleConnection 实例长期持有，没归还，新请求只能排队等——等不到就超时。
-
OracleDataReader没关：用ExecuteReader()后没调reader.Close()，也没包进using，连接就被 reader 独占着 -
using提前退出：比如if (x) return;写在using (var conn = ...)块里，conn 根本不会Dispose() -
catch里吞异常又不释放：try { cmd.ExecuteNonQuery(); } catch { log.Error(); return; }，连接丢了 - 连接字符串“看似一样”，实则分裂池：
Max Pool Size=100和Max Pool Size = 100（多一个空格）会被 ODP.NET 当作两个独立池，各自卡死在 100
为什么本地跑得好，一上 IIS 就抛 BadImageFormatException
根本不是代码问题，是 Windows 加载本机 DLL 时架构对不上。IIS 应用程序池的位数设置，会覆盖你 VS 里选的平台目标。
- 项目设成
x64，但 Instant Client 是win32包 → 崩 - 项目设成
AnyCPU（勾了“首选 32 位”），IIS 应用程序池却开了“启用 32 位应用程序” → 表面能跑，但某次部署后突然崩（因 IIS 某次回收用了不同宿主进程） - PATH 里有多个 Oracle 安装：比如 C:\oracle\11g\bin 在前，C:\instantclient\x64 在后 → 即使你放对了 x64 client，系统仍优先加载 32 位 oci.dll
- 解决方案优先级：改用
Oracle.ManagedDataAccessNuGet 包（纯托管，无 DLL 依赖）＞ 对齐位数 ＞ 清 PATH
为什么 ORA-12514 查了半天 tnspnames.ora 还是错
tnsnames.ora 是客户端“以为”的服务名，lsnrctl status 才是监听器“实际认的”。数据库注册的服务名，可能和你连了十年的写法差一个点、一个下划线、甚至大小写。
- 查真实服务名必须进数据库执行：
SELECT value FROM v$parameter WHERE name = 'service_names';或（12c+ PDB）SELECT name FROM v$services WHERE network_name IS NOT NULL; -
lsnrctl status输出里 Services Summary 下的Service "orcl.localdomain"必须和连接字符串中SERVICE_NAME=orcl.localdomain**逐字符一致**，orcl≠orcl.localdomain - 别混用
SID和SERVICE_NAME：12c+ 默认用 service_name 注册，Data Source=ORCL（旧 SID 写法）大概率失败 - Windows 上
lsnrctl status显示 HOST=localhost → 监听器只收本地请求，远程 .NET 应用连不上，哪怕服务名全对
为什么事务回滚后线程就挂住，日志却一片空白
这不是 Oracle 慢，是 DTC（分布式事务协调器）在后台锁死了状态。.NET 默认开启自动登记（Enlist=true），只要环境满足“潜在分布式条件”，哪怕只连一个 Oracle，也会触发 MSDTC 升级。
- 挂起发生点总在
TransactionScope.Dispose()或显式Rollback()后，说明控制权已移交 DTC，但它卡在 prepare 阶段 - 查 Windows 事件日志 Application 日志，搜
MSDTC和错误码0x8004d00e，常见提示 “The transaction manager has disabled its support for remote/network transactions” - 登录 Oracle 查
v$global_transaction，如果state = 'PREPARED'，基本坐实是 DTC 挂起 - 临时解法：连接字符串加
Enlist=false；长期解法：按 Microsoft 要求配置 DTC 网络访问权限（需域管理员配合）
真正难的不是定位某个异常，而是在 Open()、ExecuteReader()、Dispose() 这些调用之间，守住那条“资源必须归还”的边界——它不报错，但会悄悄拖垮整个应用。
