Eu tenho um problema onde estou vendo algumas esperas de bloqueio muito estranhas, com o processo no topo da árvore de espera de bloqueio no estado 'dormindo' 'AWAITING COMMAND'. Posso ver o nome da máquina e o aplicativo e tenho certeza de que é uma transação do lado do cliente bloqueada no lado do cliente depois de bloquear alguns registros que está causando o problema, mas não consegui descobrir por meio do exame de código o que poderia estar fazendo. Já descartei o GC, pois a mesma aplicação está respondendo a outras requisições (temos uma requisição para despejar o status de todas as requisições pendentes, cada uma com um ID único, e que retornaram bem enquanto o bloqueio permaneceu). No momento em que somos notificados sobre esse problema, o backup da solicitação é de vários milhares por máquina cliente SQL,
Gostaria de adicionar algumas informações às informações de conexão SQL para rastrear qual solicitação está no topo, não apenas qual máquina e aplicativo (e acho que isso também pode ser útil para diagnosticar problemas futuros). Eu poderia acrescentar algo ao nome do aplicativo na string de conexão, mas acho que isso provavelmente prejudicaria o pool de conexões.
Eu li esta postagem: Posso definir o valor de App_Name () DEPOIS do login?
e este: http://www.sqlservercentral.com/articles/T-SQL/2765/ que parecem indicar que eu poderia usar SET CONTEXT_INFOpara obter dados sys.dm_exec_requests.context_infoe então eu poderia usar esses dados para identificar o solicitação exata de onde vem a transação inválida.
Não estamos usando SET CONTEXT_INFOpara mais nada na aplicação (e os servidores SQL são dedicados a esta aplicação).
Existe algum motivo pelo qual eu não gostaria de fazer a identificação de solicitação dessa maneira ou alguma maneira melhor de rastrear solicitações até a camada SQL?
Agora tenho isso em produção e está funcionando perfeitamente. Encontramos o problema subjacente antes que isso fosse divulgado, mas pode ser muito útil para problemas futuros.
Para qualquer leitor futuro,
SET CONTEXT_INFOpode de fato ser usado para correlacionar solicitações SQL ao código e/ou solicitações que as executam, e não vi nenhum impacto perceptível no desempenho.Para qualquer pessoa curiosa sobre as especificidades desse problema de bloqueio, verifica-se que, nesse caso, tínhamos vários locais em nosso código onde abrimos uma transação e, durante a transação, chamamos uma função de biblioteca que, na superfície, parecia apenas recuperar um valor armazenado em cache, mas, na realidade, fez algum trabalho fora do banco de dados que não deveria ter sido feito dentro da transação e, em seguida, abriu sua própria conexão com o banco de dados. Em certas situações de alto carregamento, isso causou um impasse porque a transação bloqueou um item de alto conteúdo e, enquanto o processamento impróprio estava ocorrendo, todas as outras conexões disponíveis ficaram bloqueadas aguardando o mesmo item de alto conteúdo. Depois que o processamento foi concluído, o código errante tentou abrir a conexão de banco de dados separada, que travou porque todas as conexões disponíveis estavam em uso e aguardando a conclusão da transação. Adicionar código para detectar essa situação e registrar as pilhas de chamadas nos permitiu encontrar não apenas o caso que começou a ser acionado várias vezes por semana, mas também cinco outros casos.
Lição: deixe o banco de dados fazer tudo o que envolve cada transação (nunca use
SqlConnection.BeginTransaction). Quando você acha que precisa fazer algo do lado do cliente durante a transação, redesenhe o sistema para que não precise fazer isso - você pode pensar que está bem com a única coisa que está fazendo e pode estar, mas você nunca sabe como o código pode mudar sutilmente no futuro e quebrá-lo assim.