我们目前手上有一点情况 - 似乎有人忘了在代码中关闭连接。结果是连接池相对快速耗尽。作为临时补丁，我们将Max Pool Size = 500;添加到Web服务上的连接字符串，并在所有连接都用完后再循环池，直到我们解决这个问题。
到目前为止，我们已经做到了这一点：
SELECT SPId
FROM MASTER..SysProcesses
WHERE DBId = DB_ID('MyDb') and last_batch < DATEADD(MINUTE, -15, GETDATE())
获取15分钟未使用的SPID。我们现在尝试使用该SPID获取上次执行的查询：
DBCC INPUTBUFFER(61)
但显示的查询是多种多样的，这意味着关于连接操作的基础级别的某些内容被破坏，或者我们的推断是错误的...
我们的想法是否存在错误？ DBCC / sysprocesses是否给出了我们期望的结果，或者是否存在一些副作用？ （例如，池中的连接影响？）
（请坚持使用SQL我们可以找到的东西，因为执行代码的人很多而且现在还不在场）
答案 0 :(得分：2)
我希望inputbuffer能够记住大量不同的查询 - 根据您失败的时间和运行的查询种类，您似乎不太可能以这种方式看到一致的查询。回想一下，最终将关闭连接，但只有当它们进行GC并最终确定时才会关闭。
正如Mitch建议的那样，您需要搜索连接打开源并确保它们已本地化并包含在using（）中。还要查找可能持有连接的可能长寿的对象。在我们的目录的早期版本中，ASP页面对象保持了未正确管理的连接。
要缩小范围，您可以在关注应用的特定部分时监控连接数（perfmon）吗？在CRUD领域与报告或其他查询相比，它会发生更多吗？这可能有助于缩小你需要做的源头冲刷。
答案 1 :(得分：1)
您是否可以更改连接字符串以包含有关在“应用程序”字段中创建连接的位置和原因的信息？