Estou olhando para um impasse, que acontece quando dois processos executam uma instrução UPDATE na mesma tabela. Ambas as transações são implícitas, o que significa que abrangem apenas a instrução atual, o que, por sua vez, significa que os bloqueios que estou vendo não são um transporte de uma instrução anterior.
Há dois bloqueios e dois processos envolvidos no impasse. Um dos dois bloqueios é um bloqueio de página na tabela (um processo possui bloqueio de atualização, o outro deseja bloqueio exclusivo de intenção) e o segundo é o bloqueio de chave no índice clusterizado da tabela (um processo possui bloqueio exclusivo e o outro deseja o bloqueio de atualização).
Agora, os campos que estão sendo atualizados nas duas instruções UPDATE não fazem parte do índice clusterizado.
Ainda assim, estou me perguntando se o fato de esse índice clusterizado ter toneladas de valores duplicados pode contribuir para o impasse?
Me desculpe por não postar o rastreamento de deadlock, as instruções de atualização, a definição da tabela e do índice, é muito para ofuscar.
Minha pergunta não é como resolver meu impasse, minha pergunta é sobre o efeito do índice clusterizado de baixa cardinalidade na probabilidade de impasses em princípio.
Isso significa que a tabela é grande o suficiente para que o mecanismo tenha decidido usar bloqueios de granularidade de página para descobrir as linhas a serem atualizadas. Então, conforme ele 'drills' para realmente aplicar a atualização às linhas, o impasse ocorre porque as duas atualizações localizaram a linha a ser atualizada na mesma página. Você pode forçar o bloqueio de linha ou desativar os bloqueios de página na tabela, mas o problema real é que parece que a cláusula WHERE do UPDATE não é compatível com sARG.