Quais são as possíveis causas para que sp_reset_connection demore muito tempo para ser executado?

Por que o sp_reset_connectionprocedimento armazenado do sistema levaria mais de alguns milissegundos para ser executado, conforme exibido no SQL Server Profiler?

Peguei um rastreamento simples de um sistema de produção usando o SQL Server Profiler e usei o SqlNexus para analisá-lo. SqlNexus indica que sp_reset_connection tem a maior duração cumulativa - 33% do rastreamento geral. A duração observada varia de 0 a 7 segundos (12 a 6.833.270 microssegundos), mas a média é de 0,956s.

Entendo que sp_reset_connection está sendo chamado quando uma conexão em pool é reutilizada. Vi uma sugestão de que isso pode estar acontecendo devido a traços estranhos , mas esse não parece ser o caso.

Eu li o que o servidor está fazendo quando o sproc é chamado, mas não acredito que algum deles seja problemático nesse caso - o código não está deixando transações abertas ou grandes tabelas temporárias que precisariam ser limpas.

Também consultei /server/199974/sp-reset-connection-taking-a-long-time-to-run, mas não foi útil.

EDIT (2013-12-23): em todos os casos, as leituras e gravações são 0 e a CPU quase sempre é 0 (apenas duas instâncias de CPU diferente de zero, ambas em 16ms).

Finalmente, tive tempo para escrever uma resposta mais detalhada.

Normalmente, existem três razões principais pelas quais um procedimento simples sp_reset_connectionlevará muito tempo para ser executado.

1. Você está aguardando recursos da CPU
2. Você está bloqueado em um bloqueio em algum lugar (talvez como resultado de DML ou de uma transação concorrente)
3. Sua rede está lenta e leva muito tempo para retornar o resultado ao cliente

Anúncio 1) Se você está aguardando recursos da CPU, isso deve aparecer enquanto o sinal aguarda. Por favor, veja meu comentário sobre sua pergunta sobre como diagnosticar se este é o problema

Anúncio 2) Se você está aguardando um bloqueio, é melhor diagnosticá-lo comparando dois instantâneos de sys.dm_os_wait_stats. Veja este artigo sobre como fazer isso:

• http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanefficientdba

Se você esperar muito por LCK_ [Something], consulte sys.dm_tran_lockspara rastrear quais objetos estão sendo bloqueados. No seu caso, eu esperaria ver alguma forma de bloqueios SCH- [Algo]> bloqueando você.

Anúncio 3) A maneira mais fácil de diagnosticar problemas de rede para procurar primeiro o OLEDB e o ASYNC_NETWORK_IO aguarda na etapa 2 (se você esperar muito tempo pela rede, um deles será exibido). Se essas esperas forem altas, use xperf -on latencyou um programa de monitoramento de rede como netmon ou wireshark para verificar suas latências. Se a rede parecer lenta, isso também pode ser causado pelo fato de o servidor de aplicativos de chamada não responder com rapidez suficiente para a conexão ser reciclada.

Acabei de encontrar um artigo da KB para um bug que pode estar relacionado a esse problema. No FIX: problemas de desempenho ocorrem quando a atividade de bloqueio do banco de dados aumenta no SQL Server (KB 2926217), um dos sintomas descritos é que sp_reset_connectionpode levar muito tempo para ser concluído. O hotfix está incluído nas seguintes atualizações:

• Atualização cumulativa 17 para SQL Server 2008 SP3
• Atualização cumulativa 13 para SQL Server 2008 R2 SP2
• Atualização cumulativa 9 para SQL Server 2012 SP1
• Atualização cumulativa 1 para SQL Server 2014

O servidor no qual observei esse comportamento estava executando o SQL Server 2008 SP3 com a Atualização Cumulativa 5, portanto, é possível que ocorra esse erro. Ainda não tentei a atualização cumulativa (o problema não se repete o tempo todo), portanto não posso verificar se a correção seria ou não. No entanto, eu queria fornecer as informações caso alguém tivesse os mesmos sintomas.