Executar sp_who2 e seguir a trilha BlkBy até a causa raiz do bloqueio retorna um SPID com valores CPUTime e DiskIO de 0; ainda está bloqueando 4 outros SPIDs.
Estou confuso sobre como isso é possível; o CPUTime em particular parece estranho, pois para obter um bloqueio você teria que gastar algum tempo solicitando recursos / solicitando o próprio bloqueio.
CPUTime está em milissegundos, portanto, embora seja possível que a solicitação e o bloqueio de recursos ocorram rápido o suficiente para ter um valor arredondado aqui, isso é um pouco surpreendente.
Além disso, esses SPIDS às vezes têm alguns minutos; ainda parecem não ter feito nada além do bloqueio de causa.
Pergunta
Como é possível que um SPID cause bloqueio com tempo de CPU zero?
Estou perguntando porque suspeito que algo está faltando em minha compreensão da estatística de tempo da CPU. Se alguém puder aconselhar sobre medidas sensatas para ajudar na investigação de tais questões, isso também seria útil.
Às vezes, isso pode acontecer quando os aplicativos estão usando transações implícitas
Não ajuda que sp_who2 seja realmente confuso - Aaron está certo ao dizer que é melhor usar sp_WhoIsActive ou sp_BlitzWho para encontrar consultas em execução.
Uma oferta inoperante de transações implícitas é ver o texto da consulta como
begin tranouIF @@TRANCOUNT > 0.Isso também pode acontecer quando as consultas estão usando transações explícitas, é claro. É muito mais fácil pegá-los no código.
Quanto ao motivo pelo qual o tempo de CPU é muito baixo - bem, não é preciso muito CPU para fazer uma busca de índice em uma linha e bloqueá-la, causando problemas para qualquer outra consulta que também deseja essa linha.