SQL Server: deadlocked em recursos de buffer de comunicação de bloqueio

Qual seria o possível motivo para esse tipo de conflito? (não impasse em geral)

Bloquear recursos do buffer de comunicação

Esse sistema indicado está com pouca memória e a contagem de buffers ficou fora do limite?

Erro detalhado:

A transação (ID do Processo 59) foi bloqueada nos recursos do buffer de comunicação de bloqueio com outro processo e foi escolhida como vítima do conflito. Execute novamente a transação

A mensagem completa que é comumente vista:

A transação (ID do processo 53) foi bloqueada no bloqueio | recursos de buffer de comunicação com outro processo e foi escolhido como vítima do impasse. Execute novamente a transação.

Esse tipo de bloqueio geralmente é visto nas consultas de deadlock que o SQL Server executou como paralelo, às vezes chamado de "deadlocks paralelos dentro da consulta". Vi algumas declarações de que isso também indica que os recursos do sistema são baixos, o que acho que pode estar envolvido em um pequeno grau.

Uma diretriz geral que observei para determinar se é um deadlock paralelo é quando você puxa o gráfico de deadlock XML (que pode ser feito com a sessão system_health em 2008 e superior), você notará diferentes IDs de processo mostrando o mesmo código dentro do pilha de execução.

Além disso, consulte a lista de recursos do gráfico de deadlock e observe o tipo de evento do garçom. Eles geralmente mostram "e_xxxxxx", ou algo assim talvez:

<waiter-list>
 <waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>

Para tentar resolver o problema, vários caminhos a seguir são oferecidos on-line e em livros. Geralmente começo examinando o plano de execução da consulta / procedimento e foco as áreas que estão mostrando execução paralela. A partir daí, tente sintonizar a consulta primeiro e, como último recurso, comece a usar as dicas de consulta.

A dica de consulta mais comum que você verá mencionada para resolver esses conflitos está implementando MAXDOP 1. No entanto, antes de fazer isso, verifique se o nível do servidor MAXDOP e o Limite de custo estão definidos. O Limite de custo geralmente é definido como 5 por padrão e eu gostaria de aumentar para 35 ou 40 para começar, se a consulta em questão tiver um custo baixo para essa seção de código, talvez não seja necessário executar paralelamente. Não gosto muito de usar dicas de consulta MAXDOP, mas isso não significa que elas não tenham seu lugar e finalidade. apenas minha opinião.