我目前正在 ASP.net 2.0 应用程序上进行一些 GUI 测试。 RDBMS是SQL Server 2005。主机是Win Server 2003/IIS 6.0。
我没有该应用程序的源代码，因为它是由未发布代码的外部公司编写的。
我注意到，当我重新启动 IIS 时，应用程序运行良好，但经过一些测试，在我打开和关闭浏览器几个小时后，应用程序开始变得越来越慢。我想知道这种行为是否是由于程序员的错误关闭连接实践造成的:我怀疑这里的数据库存在打开连接泄漏。
我猜 .Net 垃圾收集器最终会关闭它们，但是......这可能需要一段时间，不是吗？
我有 SQL Server Management Studio，并且我确实从事件监视器中注意到数据库上打开了相当多的连接。
根据上面所述，以下是与主要问题相关的一些问题:
有什么办法可以知道SQL Server 2005(如果连接) 开放，因为他们正在等待 在连接池中使用或者如果 它们是开放的，因为它们被使用 应用程序？
有人知道什么是善吗？ 我可以的在线/纸质资源 学习如何使用性能 计数器或其他类型的工具 帮助追踪此类 问题？
如果性能计数器是最好的 解决方案，我的变量是什么 应该看吗？
最佳答案
发现此线程正在研究类似的问题。我想出了以下 sql 作为调试 SQL Server 中泄漏连接的好方法:
SELECT S.spid, login_time, last_batch, status, hostname, program_name, cmd,
(
select text from sys.dm_exec_sql_text(S.sql_handle)
) as last_sql
FROM sys.sysprocesses S
where dbid > 0
and DB_NAME(dbid) = '<my_database_name>'
and loginame = '<my_application_login>'
order by last_batch asc
这为您提供了特定数据库和登录上的所有打开连接，以及该连接上执行的最后一条 sql，按该 sql 执行时间排序。
由于连接池，您不能仅仅依靠有大量连接闲置的事实来告诉您存在连接泄漏，因为连接池会保留连接，即使它们已正确关闭代码。但是，如果确实存在连接泄漏，您将看到一些连接被“卡住”——它们将显示在上面的查询中，并且“last_batch”时间戳永远不会改变。其他连接也会挂起，但每次在它们上运行新的 sql 时，“last_batch”时间戳都会更新。因此，效果是卡住的连接将 float 到该查询的顶部。
如果您有相关应用程序的源代码，那么这将为您提供在孤立连接上执行的最后一条 sql，这对于调试非常有值(value)。
注意“loginame”的拼写错误(缺少“n”)位于 sys.sysprocesses View 中。上面的说法是正确的。
loginame nchar(128) Login name.
关于asp.net - 如何检测 ASP.net 应用程序中的 SqlServer 连接泄漏？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/212596/