SQL SERVER - Dicas que todo DEV deveria conhecer part-5

Nesta sequencia de tópicos abordaremos algumas dicas, que todo desenvolvedor deveria ter a oportunidade de conhecer. Todo desenvolvedor que programa em T/SQL, precisa estar atento a algumas "tips" do SQL Server que podem facilitar em seu dia-a-dia na empresa.

Dicas part-1 Transaction Log
Dicas part-2 Variáveis ​​table e JOIN's & Criação de tabelas dentro de stored procedures
Dicas part-3 Keywords performance
Dicas part-4 Ad Hoc Queries (Forced Parameteeterization)

Parte 5 - SET DEADLOCK_PRIORITY

Evite deadlock's para transações mais importantes, com a mínima alteração de código.

Hoje vamos aprender hoje como reduzir o impasse em transações importantes, com a mínima alteração de código. O requisito, não importa o que aconteça, não desejamos que essa transação entre em conflito (bloqueio). Outro requisito importante é, que não podemos alterar a regra de negocio, modificações profundas no código do sistema, sem compreender a lógica de negócios.

Nosso primeiro objetivo é, entender o que está criando o deadlock?
Depois de investigar, sempre descobrimos concorrências simultâneas em uma ou mais tabelas especificas.

De fato, a melhor solução é SEMPRE é reescrever o código para que não exista o deadlock,
mas nem sempre é possível como uma solução imediata.

Isso nos leva a apenas uma solução rápida; Definir a prioridade do deadlock.

1	SET DEADLOCK_PRIORITY HIGH;

Esta instrução quando "setada", especifica a real importância da sessão atual.

Se a sessão estiver em conflito com outra transação. Esta declaração SET certifica-se de que
a transação importante deste conteudo, não entrará em deadlock, porem as outras transações ficam em espera com uma maior frequência.

Neste cenário, o hint descrito nesta postagem reduziu o impasse para a transação importante,
mas não reduziu o número total do bloqueios. Portanto, use a técnica somentos nos casos extremamente especiais, quando não é possivel alteração de codigo, conforme detalhamos anteriormente.

Curiosidade:

• Se ambas as sessões tiverem a mesma prioridade de deadlock, a instância do SQL Server escolhe a sessão que é menos dispendiosa para ser revertida como a vítima de deadlock. Por exemplo, se ambas as sessões tiverem definido sua prioridade de deadlock como HIGH, a instância escolherá como uma vítima a sessão que calcula ser menos dispendiosa para reverter. O custo é determinado comparando o número de bytes de log gravados naquele ponto em cada transação.

Você usa deadlock priority na sua lógica de negócios?
Compartilhe sua experiência nos comentários.

Grande abraços