Azure Web App间歇性无法连接Azure SQL数据库报错排查求助

可能的报错原因 #

• Azure SQL数据库临时故障：S0属于标准层入门配置，底层基础设施偶发的维护切换、节点抖动都会导致短时间内无法建立连接，这类故障通常持续时间很短，但如果连接建立阶段的异常没有被重试策略覆盖就会抛出报错。
• DTU资源耗尽：S0仅配10 DTU，当出现偶发的慢查询、批量数据操作、突发访问峰值时，DTU使用率打满会触发SQL服务的连接节流，新的连接请求会被直接拒绝。
• 重试策略覆盖不全：EF Core默认的EnableRetryOnFailure仅覆盖EF托管的数据库操作场景，如果代码中存在手动创建SqlConnection、执行原生ADO.NET操作、事务处理等场景，这些逻辑的连接异常不会被重试捕获。
• 网络层面异常：Azure内部DNS解析临时故障、App Service到SQL数据库的链路抖动、App Service端偶发出站端口耗尽，都会导致TCP连接建立失败，触发TCP Provider error 35报错。
• SqlClient驱动bug：旧版本的Microsoft.Data.SqlClient驱动对部分TCP内部异常的处理逻辑存在缺陷，会导致本来可以重试的瞬态错误被直接抛出。

排查和解决措施 #

• 排查资源使用情况：在Azure门户查看对应SQL数据库报错时间点的DTU使用率、连接数、工作线程数指标，确认是否存在资源打满的情况；同时查看App Service的TCP连接统计，确认是否存在出站端口耗尽的问题。
• 完善重试逻辑：
  1. 升级Microsoft.Data.SqlClient的NuGet包到最新稳定版，修复驱动层面的异常处理缺陷。
  2. 在数据库连接字符串中添加Connect Timeout=30，将默认15秒的连接超时延长，适配网络抖动场景。
  3. 对代码中手动创建SqlConnection、执行原生SQL、事务操作的逻辑，用Polly等重试框架单独封装瞬态故障重试逻辑，补全EF重试覆盖不到的场景。
• 优化资源消耗：如果排查到是DTU峰值导致的问题，可通过添加缺失索引、优化慢查询降低DTU消耗，也可以将数据库配置升级到更高规格的S1及以上实例，避免资源瓶颈。
• 排查连接泄漏：检查所有数据库连接的使用逻辑，确保DbContext、SqlConnection都通过using块包裹或者依赖注入自动释放，避免连接泄漏导致连接池耗尽。
• 查看SQL侧日志：开启Azure SQL的诊断日志，记录连接失败、错误事件，报错后直接查看SQL侧的日志记录，可定位是否是服务端维护、节流导致的故障。

内容的提问来源于stack exchange，提问作者JensB