Tenho um relatório de impasse que me diz que houve um conflito envolvendo
waitresource="KEY: 9:72057632651542528 (543066506c7c)"
e eu posso ver isso:
<keylock hobtid="72057632651542528" dbid="9" objectname="MyDatabase.MySchema.MyTable" indexname="MyPrimaryKeyIndex" id="locka8c6f4100" mode="X" associatedObjectId="72057632651542528">
dentro do <resource-list>
elemento.
Quero poder encontrar o valor real da chave (id = 12345, por exemplo). Qual instrução SQL eu precisaria usar para obter essas informações?
Você tem o hobt_id, então a seguinte consulta identificará a tabela: -
A partir disso, você pode executar a seguinte instrução para identificar a linha na tabela (se ainda existir): -
Tenha cuidado com a instrução acima, no entanto, ela examinará a tabela de destino, portanto, execute READ UNCOMMITTED e monitore seu servidor.
Aqui está um artigo de Grant Fritchey sobre %%LOCKRES%% - http://www.scarydba.com/2010/03/18/undocumented-virtual-column-lockres/
E aqui está um artigo do meu próprio blog sobre o uso de %%LOCKRES%% para identificar linhas de um evento estendido:- https://dbafromthecold.wordpress.com/2015/02/24/identifying-blocking-via-extended-events/
As respostas de @Kin, @AaronBertrand e @DBAFromTheCold são ótimas e foram muito úteis. Uma informação importante que descobri durante o teste que as outras respostas foram deixadas de fora é que você precisa usar o índice que é retornado
sys.partitions
para o dadoHOBT_ID
ao procurar o%%lockres%%
(por meio de uma dica de consulta de índice). Esse índice nem sempre é o índice PK ou clusterizado.Por exemplo:
Aqui está um script de exemplo modificado usando partes de cada uma dessas respostas.
O é um complemento às respostas já postadas por DBAFromTheCold e Aaron Bertrand .
A Microsoft ainda deixou
%%lockres%%
como recurso não documentado .Abaixo está o script que irá ajudá-lo :
Consulte também esta excelente postagem no blog: O curioso caso do impasse duvidoso e do bloqueio não tão lógico
Desculpe, já estava trabalhando nessa resposta e prestes a postar quando apareceu a outra. Adicionando como wiki da comunidade apenas porque é uma abordagem ligeiramente diferente e adiciona um pouco de outras informações.
O
543066506c7c
é essencialmente um hash da chave primária e você pode recuperar essa linha (e potencialmente qualquer linha com uma colisão de hash) usando este SQL dinâmico:Você pode fazer isso sem SQL dinâmico, é claro, mas isso fornece um bom modelo para um trecho ou procedimento armazenado onde você pode simplesmente inserir os valores, se isso for algo que você soluciona muito. (Você também pode parametrizar o nome da tabela e também criar a análise da string KEY: para determinar tudo para você dinamicamente, mas achei que isso poderia estar fora do escopo desta postagem.)