artigo SQL Magazine 04 - Transações em SQL Server

Em ambientes multi-usuários existem operações que precisam ser serializadas, ou seja, colocadas em fila para que sejam executadas “uma a uma”, não permitindo tarefas em paralelo. Essas operações são amparadas por um conceito muito forte em bancos de dados relacionais denominado Transação,cujo objetivo é agrupar uma seqüência de comandos que precisam ser tratados como um bloco único e indivisível, para que se mantenham a integridade e a consistência dos dados. Veja o código abaixo:

UPDATE clientes
SET  UF=’MG’,
          Cidade=’Belo Horizonte’
WHERE codigo=1

Neste exemplo, desejamos que as colunas Cidade e UF sejam alteradas ao mesmo tempo. Caso algum erro aconteça, nenhum dos campos será modificado. A transação age da mesma forma, com a diferença de conter várias instruções SQL. Se um dos comandos não for executado, todo o bloco envolvido na transação será cancelado.

Um exemplo é uma operação bancária de transferência de fundos, onde movimenta-se dinheiro de uma conta corrente para uma conta poupança. As duas operações devem ser garantidas como uma só. Se o depósito na poupança falhar, o saque na conta corrente deve ser desconsiderado, garantindo a integridade do processo.

A transação inclui o conceito de bloqueio (lock). No momento em que ela é executada, os dados alterados permanecem visíveis somente para o usuário que a originou, ficando bloqueados para as outras conexões. Sua liberação, ou seja, a possibilidade desses dados tornarem-se novamente visíveis para outros usuários, ocorre com o término da transação. É possível determinar mecanismos de bloqueios mais avançados, como veremos mais adiante.

NOTA: O comportamento padrão de bloqueios estabelece que comandos de alteração de dados (INSERT/UPDATE/DELETE) obtêm bloqueios exclusivos, sendo liberados com o término da transação. Já comandos SELECT possuem bloqueios que terminam com a execução do próprio comando, não aguardando o desfecho da transação.

No SQL Server, existem três classes de transação:

• Transação Auto-Comitada: é padrão no banco de dados da Microsoft. Define que os comandos SQL de manipulação representam transações individuais que são automaticamente efetivadas após sua execução. Veja um exemplo na listagem 1. Na maior parte dos casos esse modelo é falho por não considerar os dois passos como um bloco único.

Listagem 1: Transação auto-comitada

• Transação Explícita: o início e o fim da transação devem ser claramente delimitados. O início é determinado através do comando begin tran. A finalização é efetuada com o comando commit, para confirmar as alterações, ou com o comando rollback, para cancelar todo o bloco. A listagem 2 contém uma transação explícita envolvendo o débito na conta corrente e o crédito na conta poupança.

Listagem 2.Transação Explícita

• Transação Implícita: Nesse modelo uma transação é iniciada automaticamente, sem o uso do comando begin tran. No entanto, o fim do bloco precisa de um commit ou rollback. A transação implícita está disponível apenas para um conjunto restrito de comandos, listados na tabela 1. Observe que as instruções SQL são agrupadas na mesma transação até que um commit ou rollback seja encontrado. Por não se tratar do modelo padrão no SQL Server, o modo implícito deve ser ativado através do comando Set Implicit_Transactions ON. A listagem 3 exemplifica uma transação implícita.

Tabela 1.Comandos que abrem transações quando implicit_transactions está ligado

Listagem 3. Transação implícita

Aninhamento de Transações

Transações podem ser incluídas uma dentro da outra. Por exemplo, uma transação pode conter uma chamada a um procedimento armazenado que abre uma nova transação. Nesse caso, teremos dois blocos de comandos que precisarão ser comitados para concluir corretamente o processo.

Para verificar se existem transações pendentes em uma sessão, utilize a variável de ambiente @@Trancount. Sempre que uma transação é aberta, essa variável, cujo escopo é local na sessão, é incrementada em uma unidade. Quando a transação é fechada seu valor é decrementado em um. Um valor igual a zero significa ausência de transações abertas, já um valor igual a dois indica duas transações pendentes na mesma sessão.

À medida que transações são aninhadas, a complexidade do código aumenta. Como as transações mais internas dependem das mais externas para serem efetivadas, em determinadas situações pode-se perder o controle de quantos commits devem ser aplicados para efetivar a transação principal. Portanto, é recomendável manter até dois níveis de aninhamento (@@Trancount=2).

Vejamos algumas regras gerais no uso de transações aninhadas:

1 ) Todo comando begin tran deve ser finalizado com um commit ou rollback;

2 ) O commit/rollback mais externo prevalece sobre os internos. Um rollback na camada mais externa gera um efeito de cascata, invalidando os commits anteriormente efetuados; já um commit mais xterno confirma também os commits internos;

3 ) Um rollback em uma transação aninhada zera @@Trancount, ou seja, age na transação atual e nas de nível superior (listagem 4).

Listagem 4.rollback

4 ) Um commit em uma transação aninhada depende do commit mais externo para que seja realmente efetivado. De fato, o commit mais interno apenas decrementa @@Trancount (listagem 5).

Listagem 5. Commit

Por Paulo Em 2008

Assine hoje e aprenda com projetos reais e mentoria

Tudo o que você precisa para entrar na tecnologia, aprender rápido e evoluir com clareza.

Conhecer Planos

Método para iniciantes

sem base nenhuma

Mentorias individuais

quando você travar

+40 projetos reais

para o seu portfólio

+5000 exercícios

para fixar o conteúdo

Suporte IA

que te ensina

No code e automações

pra entregar mais rápido

+ 3 meses de assinatura grátis!

Oferta válida para todos os planos durante o mês de dezembro

+3 MESES

Grátis

Veja os resultado dos nossos alunos

Conquistas reais de quem está aplicando o método

Conhecer Planos