为什么这么多的sp_resetconnections用于C#连接池？

Question

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

在SQL跟踪期间,我们看到许多调用"sp_resetconnection".其中大部分时间短<0.5秒,但有时我们的呼叫持续时间长达9秒.

从我读到的内容来看,sp_resetconnection与连接池有关,并且基本上重置了打开连接的状态.我的问题:

• 为什么开放连接需要重置状态？
• 为什么这么多电话!
• 什么可能导致调用sp_reset连接需要花费很多时间.

这对我来说是个谜,我很感激所有的帮助!

Answer 1

重置只是重置事物,因此您不必重新连接以重置它们.它擦除了SET或USE操作之类的连接,因此每个查询都有一个干净的平板.

该连接仍在重用.这是一个广泛的列表:

sp_reset_connection重置连接的以下方面:

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

sp_reset_connection不会重置:

• 安全上下文,这就是连接池根据确切的连接字符串匹配连接的原因
• 如果使用sp_setapprole输入了应用程序角色,则无法还原应用程序角色
• 事务隔离级别(!)