具有连接池的 ADO.NET 中的超时错误答案

【问题标题】：Timeout error in ADO.NET with connection pooling具有连接池的 ADO.NET 中的超时错误
【发布时间】：2021-01-23 10:01:24
【问题描述】：

我们有旧的 SOAP ASP.NET 网络服务，它连接到 SQL Server 数据库以检索结果集。下面是我们的连接字符串：

connectionString="server=ServerName;database=UserDBName;user id=UserNameRef;Password=myPassword;

我们将命令超时设置为 5 分钟。我们看到的是，使用连接池的 SQL Server 2012 数据库经常发生超时问题错误。服务器中没有发生重大活动或阻止问题发生。

来自sp_whoisactive 跟踪的PFB 快照。如果我们看到，会话 52 将在 5 分钟后超时。我们在此会话中没有运行任何命令。不知道为什么会突然超时。

如何解决这些超时错误？


+---------+------------+-----------+----------+---------------------------+-------------+---------------------+-------------+------------+------------+-----------------+
| status  | session_id | wait_info | sql_text |        sql_command        | login_name  | blocking_session_id |  host_name  | start_time | login_time | collection_time |
+---------+------------+-----------+----------+---------------------------+-------------+---------------------+-------------+------------+------------+-----------------+
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:00 AM | 2:39:00 AM | 2:39:00 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:06 AM | 2:39:00 AM | 2:39:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:39:31 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:39:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:40:01 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:40:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:40:31 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:40:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:41:01 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:41:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:41:31 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:41:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:42:01 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:42:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:42:31 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:42:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:43:01 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:43:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:43:30 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:43:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:44:01 AM      | <== Post this timeout occurs
+---------+------------+-----------+----------+---------------------------+-------------+---------------------+-------------+------------+------------+-----------------+

【问题讨论】：

标签： c# asp.net sql-server-2012 ado.net connection-pooling

【解决方案1】：

这闻起来像是尚未处置的资源。我可以问您“您是否在操作执行后立即处理连接和命令？”：我推荐一个using 块，它保证在块的末尾进行处理，如下所示：

string sqlConnectionString = "...(put the connection string here)...";
string commandText = "...(put the SQL command here)...";
using (var connection = new SqlConnection(sqlConnectionString))
{
    using (var command = new SqlCommand(commandText, connection))
    {
        return command.ExecuteNonQuery();
    }
}

一个不同的问题可能与连接池算法有关，这表明要从池中受益，连接字符串值非常重要：

只有具有相同配置的连接才能被池化。 ADO.NET 同时保留多个池，每个配置一个。连接按连接字符串分隔到池中，并在使用集成安全性时按 Windows 标识分隔。连接也会根据它们是否被征用在事务中。

我知道您可能已经阅读过，但这是文档的链接：SQL Server Connection Pooling (ADO.NET)

请告诉我进展如何！

【讨论】：

我无权访问代码。我将与开发人员核实并重新处理此问题。感谢您的回复。

【解决方案2】：

（按要求移到第一个答案的末尾）

【讨论】：

是的。我已经读过它了。我们为所有用户提供了相同的连接字符串。
能否请您将两个答案合并为一个答案，这样会更彻底。

【解决方案3】：

问题中的跟踪与超时问题无关。很抱歉造成的混乱。 由于阻塞问题而发生超时问题，该 ASP.NET Web 服务正在等待另一个长时间运行的 SQL 代理作业完成。

由于命令超时设置为 5 分钟，因此 SQL 代理作业写入后台表并阻止此 ASP.NET 网络服务调用。被阻塞 5 分钟后，ASP.NET 由于命令超时 5 分钟，webservice 超时。

已应用的修复：
我们在分析了长时间运行的瓶颈后台作业的执行计划后，修复了这个超时问题，通过在两个后台表上将现有的非聚集索引更改为聚集索引，从而加快了数据检索速度，减少了阻塞发生。现在，超时问题已经解决了。

【讨论】：