Esse artigo faz parte da revista SQL Magazine edição 53. Clique aqui para ler todos os artigos desta edição

east-language: EN-US">

SQL Server

Níveis de isolamento no SQL Server 2005

 

 

Uma parte importante na análise dos aplicativos e que algumas vezes não é dada a devida importância é a forma como o banco de dados deve tratar o acesso concorrente às informações. À medida que mais usuários começam a compartilhar os mesmos dados, aqueles sistemas que não tiveram um planejamento adequado estão sujeitos a apresentar problemas de desempenho, deadlocks e bloqueios que diminuem a concorrência no acesso aos dados.

 Neste artigo serão apresentados:

·         Conceitos importantes sobre como os bancos de dados tratam as transações com acessos concorrentes;

·         Problemas que podem ocorrer com a concorrência das transações;

·         Algumas das novas configurações de níveis de isolamento existentes no SQL Server 2005 que afetam a forma como o banco de dados gerencia esta concorrência.

Propriedades das transações

Transação pode ser entendida como uma série de operações sobre itens no banco de dados que podem alterar o seu estado.

As operações são delimitadas com uma instrução Begin Transaction e no final com uma instrução Commit para efetivar as alterações, ou uma instrução Rollback quando for necessário descartar todas as alterações realizadas no banco de dados.

Este conjunto de operações compreendidos dentro da transação é considerado uma unidade lógica de trabalho, desde que possua as seguintes propriedades (ACID):

·         Atomicidade: todas as ações da transação acontecem, ou nenhuma acontece;

·         Consistência: se toda a transação é consistente, e o BD inicia consistente, então o BD termina consistente;

·         Isolamento: a execução de uma transação é isolada de outras transações, ou seja, as alterações realizadas por uma transação não serão visualizadas pelas outras transações até que elas sejam efetivamente atualizadas (commit);

·         Durabilidade: se uma transação é finalizada, seu efeito persiste.

 

O conceito de transação é a base para o assunto principal desta matéria, controle de concorrência.

Concorrência

Os acessos concorrentes devem ser tratados pelos bancos de dados para garantir a integridade das alterações realizadas nas informações.

Em um mesmo momento diversos usuários podem estar realizando as mais variadas atualizações no mesmo banco de dados, e em alguns casos alterando as mesmas informações. Para solucionar este problema o banco de dados possui diferentes mecanismos, possibilitando ao desenvolvedor a escolha da melhor forma para a aplicação tratar acessos concorrentes à mesma informação.

Nos SGBDs podemos dar dois enfoques ao controle de concorrência:

 

Controle de concorrência pessimista

O SGBD garantirá a integridade das alterações a partir de bloqueios dos registros alterados. Neste caso, o alto custo para realizar um rollback das alterações justifica o bloqueio dos dados.

Este controle parte do princípio que qualquer informação usada em uma transação poderá ser necessária para outra transação concorrente.

 

Controle de concorrência otimista

Neste método as leituras de dados não realizam bloqueios. A transação transcorre normalmente até a efetivação das alterações (commit) e neste momento o SGBD verifica se alguma outra transação alterou o mesmo dado.

Caso a informação tenha sido alterada é realizado um rollback da transação e a transação é reiniciada. Este controle parte do princípio de que os conflitos serão uma exceção e raramente a transação será reprocessada.

Desta forma é evitado o custo da realização de bloqueios pelo SGBD. Este tipo de controle de concorrência não é implementado de forma automática pelo SQL Server 2005.

Problemas da concorrência de transações

Caso estejam duas ou mais transações do banco de dados efetuando alterações em determinada informação no mesmo instante, de acordo com a forma que o SGBD irá tratar estas transações poderemos ter os seguintes problemas:

·         Atualizações perdidas;

·         Dependência sem Commit – “Leituras Sujas”;

·         Análise Inconsistente – “Leituras não repetidas”;

·         Leituras Fantasmas.

 

A seguir será explicado cada um destes problemas, e no final do artigo serão apresentados os mecanismos que o banco de dados oferece de controle de concorrência para o desenvolvedor. Conforme o mecanismo adotado, a aplicação poderá enfrentar ou não alguns destes problemas.

Para ilustrar estas questões iremos começar com a definição de um procedimento de depósito, onde são passados como parâmetro o número da conta e um valor para ser somado ao saldo atual desta conta, conforme apresentado na Listagem 1.

 

Deposito (nro_conta, valor)

begin

         saldo := read(nro_conta)

         saldo := saldo + valor

         write(nro_conta, saldo)

         commit

end;

Listagem 1. Procedimento de depósito em conta corrente.

Atualizações perdidas

Considere a situação onde duas transações tentarão realizar dois depósitos para a mesma conta no mesmo instante, sendo que a primeira chamada de T1 irá depositar 50,00 e a segunda (T2) depositará 130,00.

 

Seqüência

T1 – Deposito (1,50)

T2 - Deposito (1,130)

Operação

Saldo

Operação

Saldo

1

Saldo := read(1)

100,00

 

 

2

Saldo := Saldo + 50

150,00

...

Quer ler esse conteúdo completo? Tenha acesso completo