sys.sp_reset_connection。为什么有很多？

Question

这里有很多关于 DBA EXCHANGE 的问题。但他们都帮不了我。

我有两个问题：

1）使用sp_whoisactive，我发现了很多sys.sp_reset_connection;1（我知道它们是sp_reset_connections因为我使用了dbcc inputbuffer（SPID）：

这是“主服务器”，因此其他服务器（ 3,4,7 ）在这里不断请求某些数据库的信息（我看到的是，每个请求都是针对 MASTER 数据库的）。

---

2）他们为什么要花这么多时间？

看这里的一些答案，发现系统在等待CPU。但所有 CPU 都是空的。这怎么会是问题？

在幕后，SQL Server 使用 sp_reset_connection 逻辑来“重置”SQL Server 的连接状态，这比建立全新的连接更快。较旧的驱动程序将过程调用作为单独的 TDS 往返发送到 SQL Server。
较新的客户端驱动程序在下一个命令中添加了一个标志位，从而避免了额外的网络往返。

很好……但我还是不知道该怎么办。

这不会给我带来问题。我只想知道如何解决这个问题。

Answer 1

sp_reset_connection是使用连接池的神器。你认为你看到的并不是实际发生的。

连接池是客户端库的一项功能，而不是 SQL Server 的功能。客户端提供大部分功能，而 SQL Server 本身主要提供sp_reset_connection. 使用连接池时，当应用程序代码调用“关闭连接”方法时，客户端驱动程序实际上不会关闭与 SQL Server 的物理连接。相反，驱动程序保持连接打开，并将其链接到使用完全相同的连接字符串的下一个“打开连接”请求（如果使用受信任的连接/集成安全，则来自同一个 Windows 帐户）。现在，因为连接从未关闭，SQL Server 只知道客户端保持连接打开，但不知道原因。并且因为连接保持打开状态，会话仍然存在，并且在执行最后一个命令/批处理时，任何资源和设置都已就位。这就是为什么在主作用域（即不在存储过程中）创建的临时表将继续存在的原因（详细信息请参见：Sessions, Temporary Objects, and the Afterlife )，以及打开的事务将保持打开状态。

SQL Server 不知道正在使用连接池，直到提交下一个命令/批处理，此时它执行sp_reset_connection。它是sp_reset_connection清理会话的先前状态，使其就像一个全新的会话，这是客户端代码所期望的（有一些没有被清理/重置的小项目）。

当然，该描述基于较新的驱动程序。正如问题中的引述所述，年长的司机发送了单独的sp_reset_connection. NULL使用连接池时，您会看到当前没有正在执行的请求（即 CPU 是）的会话。不典型的是sp_reset_connection通过DBCC INPUTBUFFER. 这不是典型的，因为较新的驱动程序sp_reset_connection在重新连接时提交第一批/命令时会发出请求，因此您永远不会看到，sp_reset_connection因为它永远不会是最后执行的事情（尽管您可以使用 SQL Server Profiler 或扩展事件看到它）。但是，如果你看到它使用DBCC INPUTBUFFER（即使批处理完成后，它将继续显示最后一个命令/批处理执行），那么这似乎与旧驱动程序的行为相匹配（假设旧驱动器，因为它们没有随下一个驱动器一起发送标志）命令/批处理，正在请求sp_reset_connection“关闭连接”请求）。

无论哪种方式，sp_reset_connection当前都没有运行。请求全部针对masterDB的原因很可能是master作为正在使用的登录名的默认数据库。

Answer 2

如果没有性能问题，您可能可以忽略所看到的内容。请参阅sp_reset_connection \xe2\x80\x93 速率使用情况（Don\xe2\x80\x99t 争夺葡萄）首席 SQL Server 升级工程师 Bob Dorr 的

\n\n

\n

SQL Server 在幕后使用 sp_reset_connection 逻辑来重置 SQL Server 的连接状态，这比建立全新连接要快。较旧的驱动程序将过程调用作为单独的 TDS 往返发送到 SQL Server。较新的客户端驱动程序会在下一个命令中添加一个标志位，从而避免额外的网络往返。

\n\n

讨论很快转向： \xe2\x80\x9c 我的服务器上 sp_reset_connections 的合理速率是多少？ \xe2\x80\x9d 像往常一样，答案总是视情况而定。

\n\n

没有硬性规定，但使用性能监视器，您可以快速将整体批处理速率与重置连接速率进行比较。当我看到比率开始攀升至 15% 以上时，这是一个很好的迹象，表明该应用程序可能需要重新访问并进行一些调整。

\n\n

综上所述，您需要小心不要将比率扩展得太远。在不需要时保持连接将增加连接总数，从而使用更多客户端和 SQL Server 开销。您需要找到优化客户端和 SQL Server 资源并最大化应用程序性能的最佳点。

\n\n

您还可以考虑最近的更改，这些更改减少了 SQL Server 上 sp_reset_connection 的开销

\n\n

https://support.microsoft.com/kb/2926217

\n

\n\n\n\n

丹·古兹曼还评论道：

\n\n

\n

sp_reset_connection通常不超过几毫秒（通常为微秒）。例外情况是需要回滚时，因为连接已通过打开的事务返回到池中。我怀疑当你跑步时DBCC INPUTBUFFER，这是运行的最后一个命令，而不是花费很长时间的命令。

\n

\n