Polly重试应仅监听ORA-12154、12541、03113、03114等瞬态Oracle错误，配合指数退避+抖动、事务显式回滚、幂等SQL及全链路监控。
Oracle连接异常时，Polly重试策略该监听哪些错误
Polly本身不识别数据库错误类型，必须手动判断OracleException的Number属性。Oracle官方文档明确将ORA-12154（TNS解析失败）、ORA-12541（监听器拒绝）、ORA-03113（通信中断）、ORA-03114（未连接）列为典型瞬态故障。这些错误在重试窗口内大概率可恢复，而ORA-00942（表不存在）或ORA-01403（无数据）属于业务逻辑错误，重试无意义。
实际编码中需用HandleResult或Handle配合类型检查和错误码过滤：
Policy
.Handle<oracleexception>(ex => new[] { 12154, 12541, 3113, 3114 }.Contains(ex.Number))
.Or<invalidoperationexception>(ex => ex.Message.Contains("Connection was closed"));
</invalidoperationexception></oracleexception>
- 别只捕获
Exception——会把SQL语法错误也卷入重试 - Oracle客户端版本差异可能导致部分错误码不一致，建议在测试环境触发真实断连验证
-
OracleException可能包装在AggregateException里（尤其在async/await链中），需用Flatten()展开再判断
重试间隔策略要匹配Oracle连接池行为
Oracle Data Provider for .NET（ODP.NET）默认启用连接池，但瞬态故障常导致连接池中部分连接进入“半死”状态。若重试间隔过短（如固定100ms），可能反复复用坏连接；若过长（如固定5s），又拖慢整体响应。更合理的是采用指数退避+抖动（jitter）：
WaitAndRetryAsync(
retryCount: 3,
sleepDurationProvider: retryAttempt =>
TimeSpan.FromMilliseconds(Math.Pow(2, retryAttempt) * 100) +
TimeSpan.FromMilliseconds(Random.Shared.Next(0, 100))
);
- 首次重试等待200ms左右，给Oracle监听器和网络栈缓冲时间
- 必须加随机抖动——避免多实例同时重连引发雪崩式重连风暴
- 若使用
OracleConnection.OpenAsync()，确保重试策略包裹的是整个Open调用，而非仅SQL执行
事务上下文里不能盲目重试ExecuteNonQuery
在OracleTransaction中执行ExecuteNonQuery失败后，直接重试会导致事务状态不一致：连接已断，但本地Transaction对象仍处于Active，再次提交会抛InvalidOperationException: "The transaction is not active"。正确做法是捕获异常后显式回滚并重建事务：
var policy = Policy
.Handle<oracleexception>(ex => transientCodes.Contains(ex.Number))
.RetryAsync(2, onRetry: (outcome, retryCount, context) =>
{
// 主动清理旧事务和连接
context["transaction"]?.Dispose();
context["connection"]?.Dispose();
});
<p>await policy.ExecuteAsync(async context =>
{
var conn = new OracleConnection(connStr);
await conn.OpenAsync();
context["connection"] = conn;</p>
<pre class="brush:php;toolbar:false;">var tx = conn.BeginTransaction();
context["transaction"] = tx;
using var cmd = conn.CreateCommand();
cmd.Transaction = tx;
cmd.CommandText = "UPDATE ...";
await cmd.ExecuteNonQueryAsync(); // 可能失败
await tx.CommitAsync();
});
oracleexception>- 不要依赖Polly自动重放整个
using块——资源泄漏风险高 - 把
OracleConnection和OracleTransaction作为上下文参数传递，确保每次重试都用新实例 - 写操作重试必须幂等，比如用
MERGE代替INSERT，或在SQL中加WHERE NOT EXISTS
生产环境必须监控重试失败率和延迟分布
启用Polly的onRetry回调只是第一步，真正关键的是把重试指标导出到可观测系统。比如记录每次重试的retryCount、elapsedTime、原始错误码，并打标业务场景（如“订单支付连接重试”、“库存查询重试”）：
.RetryAsync(
onRetry: (outcome, retryCount, context) =>
{
var metric = new RetryMetric
{
Operation = context.OperationKey,
ErrorCode = outcome.Exception?.InnerException is OracleException oex ? oex.Number : 0,
RetryCount = retryCount,
ElapsedMs = (long)(DateTime.UtcNow - context["startTime"]).TotalMilliseconds
};
TelemetryClient.TrackEvent("OracleRetry", metric.ToProperties());
});
- 若某类操作重试失败率持续高于5%，说明不是瞬态问题，而是配置或架构缺陷（如TNS配置错误、防火墙策略变更）
- 平均重试延迟突增往往预示Oracle监听器负载过高，需联动DBA排查
- 别忽略
context["startTime"]这类手动埋点——Polly默认不提供耗时统计
Polly重试不是银弹，它只解决“连接暂时不可达”这一层问题。Oracle侧的连接池参数（Min Pool Size、Incr Pool Size）、网络设备的TCP KeepAlive设置、甚至Kubernetes中Pod就绪探针的超时阈值，都会影响重试的实际效果。这些环节一旦脱节，策略再完善也救不了根本。
