O exemplo simples a seguir ilustra o problema de inconsistência: a partir de um caixa eletrônico um usuário faz uma transferência de valor da sua conta poupança para sua conta corrente. As seguintes operações seriam feitas pelo código sendo executado no SGBD:

     1. leia saldo da poupança em X
     2. X:= X - valor-digitado-pelo-usuário.
     3. Escreve X no  saldo da poupança.
     4. Leia saldo da conta corrente em Y.
     5. Y:= Y + valor-digitado-pelo-usuário
     6. Escreva Y no saldo da conta corrente

A prevenção desses efeitos indesejáveis é um dos principais requisitos da implementação do software de um SGBD, mesmo na presença das falhas itemizadas na lista acima. Deixando de lado,por enquanto, falhas catastróficas dos discos magnéticos, vamos expor os princípio de uma técnica comum para garantir Atomicidade da transação.

• uma área de disco (na verdade um arquivo chamado log) é reservada para armazenar todos os passos da transação (como no exemplo).
• o sistema verifica que todos os passos foram efetivamente gravados no log
• um setor do disco que pode ser lido/escrito numa única operação física (e portanto indivisível, este é o ponto fundamental!) é escrito no início da transação com uma marca especial, digamos, transação iniciada e um identificador da transação ;
• quando todos os passos da transação foram gravados e verificados o sistema grava na marca, digamos, committed.
• Neste ponto o sistema passa a fazer as operações do log nas tabelas da BD.
• quando todas as operações do log foram efetivamente gravadas na BD a marca é mudada para, digamos,finished e somente após esta gravação a transação é considerada como concluída.

Sob o ponto de vista do usuário ele usará comandos especiais para iniciar, possivelmente abortar (por exemplo, se algum recurso necessário não estiver disponível) ou concluir (commit) a transação. As operações que fazem parte da transação são comandos SQL entre o comando de início da transação e o da sua a sua finalização:

     exec sql begin transaction
     comandos SQL de leitura/escrita de dados na BD
     . . .
     exec sql commit (ou exec sql rollback)

Transações Concorrentes

• o sistema ficaria muito lento pois transações que acessam diferentes partes da BD (tabelas ou mesmo linhas distintas de uma tabela) não poderiam executar concorrentemente e isto é muito comum num sistema com muitos usuários.
• seria injusto, pois transações muito curtas teriam que esperar pelo término de uma transação muito longa.
• um mecanismo que permitisse a "serialização" de transações concorrentes e fosse "justo" segundo alguma métrica é essencial em sistemas com muitos usuários como compra de bilhetes em eventos importantes ou reserva de passagens aéreas. Tais mecanismos são chamados de "controle de concorrência de transações".

Vários algoritmos e provas matemáticas da sua correção foram desenvolvidos na década de 70. Vamos apresentar um deles: ele se baseia no conceito de lock, que permite a um processo (programa) obter acesso exclusivo a um objeto através de uma instrução indivisível especial (ou seja se ela for executada simultaneamente por dois processos um deles obtém o lock e o outro fica sabendo que não o obteve):

• Algoritmo two-phase lock (ou de locks em 2 fases):
  na fase 1 a transação procura obter todos os locks para tabelas de que precisa (ou de linhas de tabelas) Se não conseguir algum (por ter sido concedido antes para outra transação) ela fica bloqueada.
  Na fase 2 a transação que conseguiu todos os locks, e somente então, executa o commit: o sistema faz as atualizações requeridas na BD, e libera os locks da transação, permitindo outras transações bloqueadas continuarem.
  O algoritmo tem uma falha crucial: permite que duas transações T1 e T2 se bloqueiem indefinidamente caso elas acessem dois objetos da BD, digamos, A e B em ordem distinta na seguinte ordem temporal:

       T1 obtem lock sobre A
                               T2 obtem lock sobre B
       T1 pede lock sobre B  
       (T1 fica bloqueada)     T2 pede lock sobre A
                                (T2 fica bloqueada)
  

  Nesse caso diz-se que T1 e T2 entraram em deadlocK. Cadeias com mais de duas transações em mutuo deadlock são possiveis.
  É fundamental, portanto, que o SGDB implemente:
  (i) um mecanismo de detecção de deadlocks,
  (ii) uma política de quebra de deadlocks, abortando as transações com deadlocks quebrados e re-iniciando-as posteriormente.

  Uma possível otimização do algoritmo two-phase lock é conceder locks de leitura para transações que soment fazem leitura sobre um objeto: se T1 e T2 obtêm locks de leitura sobre A elas podem proceder em paralelo sem bloqueio (o lock de leitura é necessário, porém, caso uma outra transação tente obter um lock de escrita sobre A).

  Níveis de isolação de transações em SQL/92

  Serializibilidade é a política padrão de contrôle de concorrência em SQL. Há aplicações que ficam mais ágeis com políticas menos rígidas, relaxando a exigência de serializibilidade. Elas são chamadas de "niveis de isolamento" e são aplicadas através dos seguintes comandos imediatamente antes do início da transação (no exemplo supomos que T1 tem um lock sobre um objeto A e faz múltiplas atualizações sobre A; T2 obtem o lock especial sobre A e faz múltiplas leituras de A):
  1. set transaction isolation level repeatable read
     nesse caso T2 deve sempre ler o mesmo valor para A.
  2. set transaction isolation level read committed
     nesse caso T2 poderia ler valores diferentes de A desde que eles tenham sido escritos por transações (distintas) que terminaram com sucesso.
  3. set transaction isolation level read uncommitted
     nesse caso T2 lê um valor que T1 eventualmente não gravou na BD porque abortou a transação, ou seja, T2 lê um valor que nunca existiu de fato na BD! Por incrível que pareça pode ser útil neste exemplo:

         T1 (um agente de viagens) reserva o assento A no vôo Y.
         T2  (outro agente de viagens) tenta reservar o assento A no vôo Y mas não consegue
         o cliente de T1 cancela o vôo e T1 libera o assento A
     

Consistência em Sistemas Distribuídos NoSQL