超时必须分三层配，只改CommandTimeout不够：ConnectionTimeout控制建立连接等待时间（默认15秒），CommandTimeout控制命令执行到首行返回的等待时间（默认30秒），Oracle端SQLNET.INBOUND_CONNECT_TIMEOUT等服务端超时参数若更小，会优先中断连接。
直接结论：超时必须分三层配，只改 CommandTimeout 不够，连接层和数据库层不配合，照样超时失败。
Connection Timeout 控制的是“连上数据库”要等多久
这是连接字符串里的 Connection Timeout（单位秒），它只管从发起 TCP 连接开始，到收到 Oracle 服务端 ACK + 完成 TNS 握手为止。如果这里超时，你会看到 OracleException 带 ORA-12170 或 ORA-12537。
常见错误配置：
- 设成
Connection Timeout=1—— 网络抖动就断，尤其跨机房或容器环境 - 完全没写这个参数 —— 默认是 15 秒，但某些 Oracle 客户端版本会退化为无限等待
- 和
Async=true混用却没关连接池（Pooling=false）—— 高并发下连接池抢不到空闲连接，Connection Timeout实际失效
推荐值：Connection Timeout=30（测试环境可放宽到 60），并确保连接字符串含 Async=true;Pooling=false（异步场景下）。
CommandTimeout 控制的是“SQL 执行完”要等多久
这是 OracleCommand.CommandTimeout 属性，也是 EF Core 里 DbContext.Database.CommandTimeout 的底层映射。它生效前提是连接已建立、命令已发到 Oracle 服务端。
容易被忽略的点：
- EF Core 中若用
FromSqlRaw或存储过程，CommandTimeout必须在执行前显式设置，不能只靠全局配置 - Oracle 侧有独立的
SQLNET.INBOUND_CONNECT_TIMEOUT（单位秒），若该值小于CommandTimeout，Oracle 会在服务端主动 kill 掉正在执行的会话，.NET 侧抛出ORA-609或TNS-12537 - 使用游标分页（
WHERE created_time ）时，CommandTimeout要预留索引扫描+网络传输时间，别盲目设成 30 秒——百万级表上可能需要 90 秒+
实操建议：在 DbContext 构造中统一设默认值，再按需覆盖：
optionsBuilder.UseOracle(connectionString, opt =>
{
opt.CommandTimeout(120); // 全局默认 120 秒
});
Oracle 服务端参数必须同步调优，否则.NET侧设置无效
.NET 的超时只是客户端行为，Oracle 实例本身也有三道闸门：
-
SQLNET.EXPIRE_TIME=10（单位分钟）：启用死连接检测，避免连接假死占用资源；但设太小（如 1）会导致长查询中途被断开 -
SQLNET.INBOUND_CONNECT_TIMEOUT=180（单位秒）：必须 ≥ .NET 侧CommandTimeout，否则 Oracle 主动 abort 进程，日志里出现ospid(xxxx) process is being aborted -
_asm_hbeatiowait=120（ASM 实例专用）：若用 ASM 存储且报Waited XXX secs for write IO to PST disk，这个隐含参数不调，IO 卡顿会传导为 SQL 执行超时
验证方式：查 v$session，看 last_call_et 和 status，长期 INACTIVE 但 last_call_et > 300，说明服务端已放弃该会话。
EF Core 场景下最容易漏掉的 NLS 隐式转换陷阱
你把 CommandTimeout 设成 300 秒，结果 5 秒就超时报 ORA-04030 或卡死 CPU —— 很可能不是超时设置问题，而是执行计划崩了。
典型诱因：
-
NLS_DATE_FORMAT和 C#DateTime传参格式不一致，触发TO_DATE()隐式转换，导致索引失效 -
NLS_COMP=LINGUISTIC开启后，WHERE name = 'abc'变成函数索引扫描，百万行表变全表扫 - EF Core 自动生成的
OFFSET 10000 FETCH NEXT 100 ROWS ONLY在 Oracle
对策不是加超时，而是查 EXPLAIN PLAN，确认 Operation 列是否出现 FILTER、SORT ORDER BY 或多层 VIEW；然后在连接初始化时强制对齐 NLS：
OracleConfiguration.ConnectionInitialization = conn =>
{
using var cmd = conn.CreateCommand();
cmd.CommandText = "ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'";
cmd.ExecuteNonQuery();
};
真正卡住的从来不是超时数字本身，而是连接、命令、服务端、NLS 四者没对齐。调一个参数就以为搞定，往往只是把超时从 30 秒拖到 35 秒而已。
