Найдена эта тема, исследующая похожую проблему. Я придумал следующий 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 loginname = '<my_application_login>'
order by last_batch asc
Это дает вам все открытые соединения в конкретной базе данных и имени входа, вместе с последним sql, выполненным для этого соединения , отсортированным по времени, когда этот sql был выполнен.
Из-за пула соединений вы не можете просто полагаться на тот факт, что вокруг висит много соединений, чтобы сказать вам, что у вас есть утечка соединений, потому что пул соединений будет держать соединения вокруг, даже если они закрыты правильно от код. Однако, если у вас есть утечка соединения, вы увидите, что некоторые соединения «зависли» - они отобразятся в приведенном выше запросе, а отметка времени «last_batch» никогда не изменится. Другие соединения также будут зависать, но каждый раз, когда на них запускается новый sql, отметка времени «last_batch» обновляется. Таким образом, эффект заключается в том, что замороженные соединения будут всплывать в верхней части этого запроса.
Если у вас есть исходный код рассматриваемого приложения, тот факт, что он дает вам последний sql, выполненный для потерянного соединения, очень важен для отладки.