DeadLocks – SQL Server

No SQL Server, deadlock ocorre quando duas ou mais transações se bloqueiam. Isto acontece porque cada uma destas transações possui um lock sobre um recurso que qualquer outra está tentando bloquear.

Exemplos:

– A transação X têm um lock de leitura do registro 1 e A transação Y têm um lock de leitura do registro 2;
– A transação X solicita um lock de escrita sobre o registro 2 e esta fica bloqueada até que a transação Y libere o lock que contém e vice-versa. Com isto nenhuma das transações tem condições em “continuar”, assim gerando um deadlock.

O SQL Server possui um mecanismo chamado Deadlock Monitor. Este mecanismo analisa as transações ativas periodicamente para localizar estes tipos de situação. Quando o monitor encontra uma ocorrência de deadlock, o monitor termina automaticamente com o erro destas transações de forma que a outra transação termine normalmente. Esta transação interrempoida é conhecida como “deadlock victim” e é escolhida por alguns critérios baseados no custo de seu respectivo ROLLBACK.

Os deadlocks podem ocorrer sobre vários tipos de recursos, como registros, páginas, tabelas, índices… e por várias operações (não é necessário que exista um lock exclusivo antes da leitura dos dados pela segunda transação).

Na realidade, é possível a ocorrência de dealocks no SQL Server também sobre outros recursos do sistema não diretamente relacionados com os dados como, por exemplo, blocos de memória ou worker threads.

Para tratar um ocorrência de um deadlock, ele efetua as seguintes operações:
Quando é deadlock é detectado ele seleciona uma das transações como vítima, cancela a operação , desfaz todas as operações realizadas por esta transação (ROLLBACK) e devolve uma mensagem de erro.

Em teoria qualquer aplicação que submeta queries à base de dados pode vir a ser seleccionada como vítima num deadlock. Por isso, qualquer aplicação deve incluir um tratamento de erros específico. Então o “error handler” poderá voltar a submeter a mesma transação de modo que o utilizador poderá mesmo nem se aperceber do erro ocorrido. É recomendável que a aplicação seja parada por um período de tempo aleatório antes de o fazer de modo a dar tempo à outra transação para terminar e libertar os recursos que causaram o erro. É importante que esse tempo seja aleatório para evitar que, se, por exemplo, duas transações sejam canceladas para terminar o dealock não voltem a tentar a transação em simultâneo.

E para minimizar?… Existem algumas regras básicas de implementação da transação! Por exemplo, não realizar outros comandos com um utilizador dentro de uma transação e reduzir ao máximo a duração e o número de operações de cada transação. É importante, juntar os recursos pela mesma ordem nas transações concorrentes!

Existes alguns casos particulares aonde você pode utilizar um nível de isolamento inferior (para reduzir a duração dos locks) e utilizar o “bound connections” (quando usadas, todas as conexões abertas pela mesma aplicação podem cooperar entre si, “partilhando” os locks adquiridos por cada uma, logo nunca se bloqueando entre si).

Resumindo, um deadlock é uma das condições de erro mais fáceis de se compreender, porém é um dos erros mais difíceis de diagnosticar e resolver porque envolve, na maioria das vezes, encontra-se um nível de concorrência maior do que se espera…

Alan Machado

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s