Artigo SQL Magazine 53 - Níveis de isolamento no SQL Server 2005

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.