标签: sp-reset-connection

试图通过发出"sp_reset_connection"来理解Sql Profiler的含义.

我有以下,"exec sp_reset_connection"行后跟BatchStarting和Completed,

RPC:Completed       exec sp_reset_connection
SQL:BatchStarting   SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]
SQL:BatchCompleted  SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]    

基本上第一行"exec sp_reset_connection"意味着整个过程(我的连接被打开,选择stmt运行,然后连接关闭并释放回池)刚刚发生？或者我的联系仍处于开放阶段.

而且,为什么sp_reset_connection在我自己的select语句之前执行,不应该在用户的sql之后复位吗？

我想知道有什么方法可以更详细地了解连接何时打开和关闭？

通过查看"exec sp_reset_connection",这是否意味着我的连接已关闭？

我的探查器跟踪显示exec sp_reset_connection在每个sql批处理或过程调用之间调用.这是有原因的,但是如果我确信没有必要提高性能,我可以阻止它被调用吗？

更新:我认为这可以提高性能的原因有两个:

1. SQL Server不需要重置连接状态.我认为这将是一个相对微不足道的改进.
2. 减少网络延迟,因为客户端不需要发送exec sp_reset_connection,等待响应,然后发送它真正想要执行的任何sql.

第二个好处是我感兴趣的那个,因为在我的架构中,客户端有时与数据库有一定距离.如果每个sql批处理或rpc都需要双向往返,则会使任何网络延迟的影响加倍.消除这种双重调用可能会提高性能.

是的,我可以做很多其他事情来改善性能,比如重新构建应用程序,我是解决问题根本原因的忠实粉丝,但在这种情况下我只想知道是否可以阻止sp_reset_connection被称为.然后我可以测试是否有任何性能改进,并正确评估不调用它的风险.

这提示了另一个问题:与sp_reset_connection的网络通信是否真的如上所述？即客户端是否发送exec sp_reset_connection,等待响应,然后发送真正的SQL？或者这一切都在一块？

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

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

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

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

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