oracleconnection 不支持自动重连，必须由应用层显式实现重试逻辑。odp.net core 无内置重试机制，连接字符串中的 retry_count 等参数被忽略；重连需封装 openwithretry 扩展方法并配合 dbcontext 重建以保证事务一致性。
oracle 数据库连接在 asp.net core 中不会自动重连——oracleconnection 打开后一旦网络中断或会话失效，open() 或 executereader() 就会直接抛出异常，不会尝试恢复。必须由应用层主动干预。
为什么 OracleConnection 不像 SqlConnection 那样支持连接字符串里的 retry 参数
SQL Server 的 SqlConnection 支持 Connect Timeout 和底层驱动隐式重试（如 .NET 6+ 的 RetryInterval），但 Oracle 的 ODP.NET Core（Oracle.ManagedDataAccess.Core）**不提供任何内置重试逻辑**。它的连接行为是“一次打开，失败即止”，所有重连必须显式编码实现。
-
OracleConfiguration.CommandTimeout只控制命令执行超时，不影响连接建立过程 -
OracleConfiguration.SelfTuning = true是性能自调优开关，和连接可靠性无关 - tnsnames.ora 或连接字符串中的
(RETRY_COUNT=3)等参数在 ODP.NET Core 中被忽略，仅对 Oracle 客户端工具（如 sqlplus）有效
在 DbContext 层封装带重试的 Oracle 连接打开逻辑
EF Core 的 DbContext 默认使用 OracleConnection，但其 OnConfiguring 中的 UseOracle() 不暴露连接建立细节。要加重试，得绕过默认流程，在 SaveChangesAsync 或查询前手动控制连接状态：
- 重写
SaveChangesAsync：先检查Database.CurrentTransaction == null && Database.GetDbConnection().State != ConnectionState.Open，再用OpenWithRetry()方法重试 - 定义一个扩展方法
OpenWithRetry(this OracleConnection conn, int maxRetries = 3, int delayMs = 1000)，内部用for循环 +try/catch捕获OracleException（如 ORA-12170、ORA-03113、ORA-01012） - 每次失败后按指数退避等待：
delayMs = (int)Math.Min(delayMs * 2, 10_000) - 注意：不能在
OnConfiguring里调用Open()，否则 EF Core 初始化会卡死
避免事务上下文污染的关键点
重连本身容易，但真正难的是保证事务一致性。如果第一次操作因断连失败，而你重连后直接继续执行，很可能丢失事务边界或造成部分提交：
- EF Core 的
BeginTransaction()绑定到具体连接实例，重连后旧事务对象已失效，继续Commit()会报InvalidOperationException: The connection is not open - 正确做法：所有涉及事务的操作（尤其是
SaveChangesAsync）必须包裹在try/catch内，并在捕获连接类异常后 **丢弃当前DbContext实例，新建一个**，重新加载必要数据再重试 - 不要复用
DbContext：它不是线程安全的，也不设计用于跨连接生命周期存活 - 若用仓储模式，确保每个业务方法都接受新构造的
DbContext，而非依赖单例或长生命周期实例
最易被忽略的其实是连接池干扰——ODP.NET 默认启用连接池，断连后释放的物理连接可能被标记为“无效”但仍留在池中，下次 Open() 可能复用它并立即失败。可在连接字符串加 Pooling=false 临时验证是否为池问题，但生产环境应配合 OracleConfiguration.ConnectionTimeout = 15 和更激进的池清理策略，而非禁用池。
