Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo SQL Magazine 5 - Conceitos e Otimização de bloqueios no SQL Server
Artigo da Revista SQL Magazine edição 05.
Atenção: por essa edição ser muito antiga não há arquivo PDF para download.
Os artigos dessa edição estão disponíveis somente através do formato HTML.
Clique aqui para ler todos os artigos desta edição
Conceitos e Otimização de bloqueios no SQL Server
A arquitetura de ambientes transacionais é fundamentada no conceito segundo o qual, para que haja consistência de informações, é necessário que se estabeleçam regras rígidas no acesso a dados. Essas regras não permitem, por exemplo, que dois usuários compartilhem a mesma alteração ou excluam o mesmo registro em uma tabela. Para executar essas restrições, o banco utiliza um recurso denominado bloqueio (lock) em transações.
O ato de abrir uma transação sinaliza para o banco que as tabelas manipuladas deverão ser tratatas com algum tipo de bloqueio para que sejam consistentes.
O SQL Server efetua bloqueios sempre no menor recurso disponível, para viabilizar maior concorrência. Isso evita cenários não coerentes, como bloquear uma tabela para alterar apenas uma linha. A situação ideal é que seja bloqueado somente o set de registros manipulados na transação, liberando, assim, acessos concorrentes a outros registros na mesma tabela.
No entanto, bloqueios consomem recursos - cada um gasta 64 bytes e cada processo aguardando a liberação do recurso bloqueado consome 32 bytes de memória. Por economia, sempre que a quantidade de bloqueios na sessão excede um limite interno, eles são promovidos à níveis mais abrangentes. Dessa forma, bloqueios de linha e/ou página podem ser transformados em bloqueios de tabela. Sempre que acontece o escalonamento, os bloqueios de nível mais baixo são liberados.
Os recursos que podem ser bloqueados, em ordem crescente de granulidade, estão listados na tabela 1.
NOTA: Bloqueios de linha nunca são promovidos para bloqueios de página.
NOTA: Granulidade diz respeito à abrangência do bloqueio, ou seja, se afeta uma linha, página ou tabela.
Tipos de Bloqueio
Os bloqueios podem diferir quanto ao recurso bloqueado (linha, página, extent, tabela ou database), duração (se permanecem ou não ativos durante toda a transação) ou tipo (Shared, Update, Exclusive, Intent, Schema ou Bulk Update). Os tipos são detalhados a seguir:
Shared (S): utilizados para processos de leitura. Ao se aplicar um comando SELECT, um bloqueio do tipo shared é efetuado. Sua finalidade é restringir alterações de dados e/ou de estrutura nos objetos que estão sendo lidos. Shared locks são compatíveis entre si; ou seja, é possível executar vários SELECTs para uma mesma tabela sem que uma sessão trave a outra. Quando executados sob o nível de isolamento read committed permanecem ativos somente durante a execução do comando. Em isolamentos repeatable read ou serializable, permanecem ativos até o término da transação.
Update (U): são utilizados em processos de alteração/exclusão de dados. Para entender seu uso, devemos notar que um UPDATE, de forma geral, é antecedido de uma leitura do conjunto de registros que será alterado. Por exemplo:
UPDATE FROM funcionarios
SET salario = salario * 1.10
WHERE depto = 5
Antes de iniciar a alteração o SQL Server recupera todos os funcionários do departamento 5, promovendo um update lock durante a leitura (e não durante a alteração em si). Update locks não são compatíveis entre si, ou seja, não é permitido mais de um bloqueio para um mesmo recurso em paralelo – o que evita a ocorrência de deadlocks de conversão. Após a leitura dos dados, o bloqueio é promovido para exclusive e a alteração é efetuada. Com esse mecanismo, O SQL Server garante maior concorrência durante a atualização.
Nota: Maiores detalhes sobre deadlocks de conversão estão disponíveis na SQL Magazine 2.
Exclusive (X): acionado no momento em que a alteração/exclusão efetivamente acontece. Um bloqueio exclusivo assegura que um e somente um processo estará manipulando o conjunto de registros definido na transação. Como o nome sugere, eles não são compatíveis com qualquer outro tipo de bloqueio, sendo liberados somente no término da transação.
Intent (I): um intent lock nada mais é do que uma “marca” sinalizando que existem bloqueios de menor nível hierárquico sendo executados. Por exemplo, um processo que detém um lock exclusive de linha gera também dois intent exclusive locks: um para a página onde se encontra o registro e outro para a tabela. A finalidade do intent lock é evitar o conflito de recursos. Imagine que um processo necessite de um bloqueio exclusivo de tabela. Se existem intent locks ativos neste objeto, o bloqueio não poderá ser honrado.
"
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
