IIS托管第三方VB Web应用突发数据库连接丢失问题排查咨询

针对你遇到的IIS上VB Web应用通过Delphi编写的DLL连接SQL Server时突发Missing Connection or ConnectionString错误，以下是可能的原因、监控方案及排查建议：

可能的触发原因 #

• 连接池耗尽或连接泄漏：尽管配置了Max Pool Size=50，但如果Delphi DLL未正确释放数据库连接（比如未调用连接对象的Close/Free方法），或者业务请求突增导致连接池无可用连接，会触发此类错误。部分旧版Delphi数据组件（如BDE、早期ADO组件）在连接池管理上存在缺陷，易出现连接泄漏。
• 数据库端连接中断：SQL Server重启、网络波动、防火墙临时阻断等情况会导致DLL持有的连接失效，若组件未实现自动重连逻辑，就会抛出连接缺失错误。
• IIS应用池回收影响：应用池回收后，DLL中存储的全局连接对象可能被销毁，而Web应用未在回收后重新初始化连接，导致后续请求调用DLL时无可用连接。
• 线程安全问题：若Delphi DLL使用了非线程安全的数据库组件，多并发请求下会导致连接状态混乱，触发连接缺失的错误。
• 驱动兼容性问题：SQLNCLI11与部分Delphi组件的MARS（MultipleActiveResultSets）特性可能存在兼容性冲突，即使开关MARS都出现问题，也可能是驱动版本或组件内部逻辑的隐性冲突。

需监控的指标与性能计数器 #

SQL Server端 #

• SQL Server:General Statistics\User Connections：实时监控数据库总连接数，判断是否接近连接池上限或SQL Server默认最大连接数（默认100）。
• SQL Server:Connection Pooling\Pooled Connections：查看连接池的活跃连接数，若频繁达到Max Pool Size，则说明连接池耗尽是主要诱因。
• SQL Server:SQL Statistics\Batch Requests/sec：对比错误发生时间点的请求量，确认是否因请求突增导致连接资源不足。

Windows/IIS端 #

• Process:Private Bytes（对应w3wp.exe进程）：监控Web应用进程的内存占用，若持续增长，可能存在DLL内存泄漏导致连接状态异常。
• ASP.NET Applications:Requests Queued：若请求排队数突增，说明应用处理能力不足，易引发连接池资源竞争。
• TCP/IP:Connections Established：监控Web服务器与SQL Server之间的TCP连接数，查看错误发生时是否有连接突然断开的情况。

自定义补充监控 #

在错误捕获逻辑中，额外记录以下信息：

• 错误发生的时间戳、当前应用池ID
• 若能通过代码获取，记录连接池的当前可用连接数（部分ADO组件支持通过ConnectionPooling相关属性查询）
• 服务器CPU、内存的实时使用率

排查与修复建议 #

1. 调整连接池配置：临时将Max Pool Size调至100，观察错误是否减少。若错误频率降低，说明连接池耗尽是核心问题，需进一步排查DLL的连接释放逻辑。
2. 启用SQL Server跟踪：使用Extended Events或SQL Server Profiler捕获错误发生前后的连接事件，查看是否存在连接失败、强制断开的记录，定位数据库端的异常。
3. 开启IIS失败请求跟踪：配置IIS的Failed Request Tracing，跟踪错误发生时的请求流程，确认错误是否在调用Delphi DLL的环节触发，以及请求的上下文信息。
4. 检查应用池回收设置：查看应用池的回收规则（如固定时间回收、内存阈值回收），若错误发生时间与回收时间吻合，可尝试禁用回收或调整回收时间，同时确保应用在回收后能重新初始化DLL的连接。
5. 更换SQL驱动版本：尝试切换至ODBC Driver 17 for SQL Server或SQLNCLI10，排查是否为SQLNCLI11与Delphi组件的兼容性问题。
6. 监控DLL的配置读取：使用Process Monitor工具监控Delphi DLL的文件访问、注册表读取操作，确认错误发生时是否存在连接字符串配置文件读取失败的情况。

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