8

我们有一个用 C# 编码的 Web 服务，它可以多次调用 MS SQL Server 2005 数据库。该代码使用结合 C# 的连接池的 Using 块。

在 SQL 跟踪期间，我们看到了许多对“sp_resetconnection”的调用。其中大多数都很短 < 0.5 秒，但有时我们会接到长达 9 秒的通话。

从我读到的 sp_resetconnection 与连接池有关，基本上重置了打开连接的状态。我的问题：

  • 为什么打开的连接需要重置其状态？
  • 为什么这么多电话！
  • 什么可能导致调用 sp_reset 连接花费大量时间。

这对我来说是个谜，我感谢任何和所有的帮助！

4

4 回答 4

12

重置只是重置事物，因此您无需重新连接即可重置它们。它清除了诸如 SET 或 USE 操作之类的连接，因此每个查询都有一个干净的状态。

该连接仍在被重用。这是一个广泛的列表：

sp_reset_connection 重置连接的以下方面：

  • 它重置所有错误状态和数字（如@@error）
  • 它停止作为执行并行查询的父 EC 的子线程的所有 EC（执行上下文）
  • 它将等待任何未完成的 I/O 操作
  • 它将通过连接释放服务器上任何持有的缓冲区
  • 它将解锁连接使用的任何缓冲区资源
  • 它将释放连接拥有的所有分配的内存
  • 它将清除连接创建的所有工作表或临时表
  • 它将杀死连接拥有的所有全局游标
  • 它将关闭所有打开的 SQL-XML 句柄
  • 它将删除任何打开的 SQL-XML 相关工作表
  • 它将关闭所有系统表
  • 它将关闭所有用户表
  • 它将丢弃所有临时对象
  • 它将中止打开的交易
  • 入伍时它将脱离分布式事务
  • 它将减少当前数据库中用户的引用计数；释放共享数据库锁
  • 它将释放获得的锁
  • 它将释放任何可能已获取的句柄
  • 它将所有 SET 选项重置为默认值
  • 它将重置@@rowcount 值
  • 它将重置@@identity 值
  • 它将使用 dbcc traceon() 重置任何会话级别的跟踪选项

sp_reset_connection 不会重置：

  • 安全上下文，这就是连接池根据确切的连接字符串匹配连接的原因
  • 如果您使用 sp_setapprole 输入了应用程序角色，因为应用程序角色无法恢复
  • 事务隔离级别（！）
于 2009-06-07T17:15:28.553 回答
1

这里解释一下sp_reset_connection 是做什么的？其中说，部分“数据访问 API 的层（如 ODBC、OLE-DB 和 SqlClient）在重新使用来自连接池的连接时调用（内部）存储过程 sp_reset_connection。它这样做是为了在连接之前重置连接状态重复使用。” 然后它给出了系统存储过程的一些细节。那是一件好事。

于 2009-06-07T17:24:36.513 回答
1

每次您从池中请求新连接时，都会调用 sp_resetconnection。它必须这样做，因为池不能保证用户（您，可能是程序员:) 已将连接保持在正确的状态。例如，返回带有未提交事务的旧连接将是..bad。

调用的 nr 应该与您获取新连接的次数有关。

至于一些花费大量时间的电话，我不确定。可能是服务器当时正忙于处理其他内容。可能是网络延迟。

于 2009-06-07T17:40:02.717 回答
1

基本上，这些调用是清除状态信息。如果您有任何打开的 DataReader，则需要更长的时间才能发生。这是因为您的 DataReaders 只保存一行，但可以拉更多行。在重置可以继续之前，它们每个都必须被清除。因此，请确保您拥有 using() 语句中的所有内容，并且不会在您的某些语句中留下任何内容。

发生这种情况时，您总共运行了多少个连接？

如果你最多有 5 个并且你击中了所有 5 个，那么调用重置将阻塞 - 而且它似乎需要很长时间。确实不是，它只是被阻塞等待池连接变为可用。

此外，如果你在 SQL Express 上运行，你很容易因为线程要求而被阻塞（也可能在完整的 SQL Server 中发生，但可能性要小得多）。

如果关闭连接池会发生什么？

于 2009-06-09T21:14:22.827 回答