21 Transações

Prévia do material em texto

Introdução aos conceitos e 
teoria de processamento de 
transações
Disciplina: Banco de Dados
Professor: Wandré Nunes de 
Pinho Veloso
2
Introdução
• Sistema de processamento de transações
– Grandes Bancos de Dados
– Monousuário
• Computador pessoal
– Multiusuário
• Acesso simultâneo ao Banco de Dados, baseado 
na capacidade do Sistema Operacional de lidar 
com múltiplos programas em execução simultânea
• Acessos múltiplos ao banco de dados, em 
sistemas dotados de mais de um processador 
(processamento paralelo)
3
Concorrência intercalada e paralela
• Processos A e B estão executando de forma intercalada
– Um pode realizar E/S e outro pode processar, ao mesmo tempo, 
tendo ganho de tempo
• Processos C e D estão executando de forma paralela
– Somente com mais de um processador
4
Introdução
• Uma transação é um programa em execução que 
forma uma unidade lógica de processamento de 
Banco de Dados
• Inclui uma ou mais operações do Banco de Dados 
(inclusão, exclusão, modificação, 
consulta/recuperação)
• Essas operações podem estar embutidas em um 
programa em uma linguagem hospedeira, ou ser 
especificadas em uma linguagem de consulta de 
alto nível (SQL)
• Uma maneira de definir a transação é delimitar os 
comandos nela incluídos usando BEGIN 
TRANSACTION... END TRANSACTION
5
Introdução
• Um programa pode conter diversas transações
• Se as operações não modificam o estado do 
Banco de Dados, a transação é chamada de 
transação read-only
• Para trabalhar com transações, usa-se um 
modelo simplificado das operações do BD
– read_item(X)
– write_item(X)
6
Introdução
• read_item(X)
– Ache o endereço do bloco de disco que contém o item X
– Copie esse bloco de disco para um buffer na memória principal 
(se esse bloco ainda não estiver em algum buffer de memória)
– Copiar o item X do buffer para a variável de programa chamada 
X
• write_item(X)
– Ache o endereço do bloco de disco que contém o item X
– Copie esse bloco de disco para um buffer na memória principal 
(se esse bloco ainda não estiver em algum buffer de memória)
– Copie o item X da variável de programa chamada X para o local 
correto no buffer
– Armazenar o bloco atualizado do buffer de volta no disco 
(imediatamente ou em algum momento posterior)
7
Introdução
• Nem sempre o bloco atualizado é imediatamente 
gravado em disco
– O SGBD manterá na cache do Banco de Dados uma série 
de buffers de dados na memória principal
• Pode ficar no buffer mais algum tempo, prevendo 
mais atualizações
• Quem gerencia essa decisão é o gerenciador de 
recuperação, juntamente com o mecanismo de 
memória virtual e paginação do SO
• Os buffers do SGBD são mantidos em memória até 
que não haja mais espaço para blocos adicionais; 
quando isso acontece, um buffer é gravado no disco 
para abrir espaço
8
Controle de concorrência
9
Controle de concorrência
• No exemplo, se T1 e T2 forem disparadas ao mesmo 
tempo, teríamos dois processos tentando alterar 
simultaneamente o valor de X
• O resultado final depende de quem teria a precedência 
na execução, e pode afetar a integridade do banco e a 
confiabilidade dos resultados
• Alguns tipos de problemas podem ocorrer com 
transações que são executadas de forma concorrente:
– Problema da atualização perdida (lost update)
– Problema da atualização temporária (dirty read)
– Problema do sumário incorreto (incorrect summary)
– Problema da leitura não repetitiva (no repeatable read)
10
Controle de concorrência
• Problema da atualização perdida
– Duas transações que acessam os mesmos 
itens do BD têm suas operações intercaladas 
de modo que isso torna o valor de alguns 
itens do BD incorreto
– No exemplo a seguir, o valor final do item X é 
incorreto, se as duas transações forem 
submetidas ao mesmo tempo, porque T2 lê o valor de X antes que T1 o mude no BD, e, portanto, o valor atualizado resultante de T1 é perdido
11
Controle de concorrência
Item X tem um 
valor incorreto 
porque sua 
atualização 
por T1 é 
perdida 
(sobrescrita)
12
Controle de concorrência
• Problema da atualização temporária (ou 
leitura suja)
– Uma transação atualiza um item do BD e 
depois a transação falha por algum motivo
– Nesse meio-tempo, o item atualizado é 
acessado (lido) por outra transação, antes de 
ser alterado de volta para seu valor original
– O valor do item que foi lido pela outra 
transação é chamado de dado sujo, pois foi 
criado por uma transação que não foi 
concluída nem confirmada
13
Controle de concorrência
Transação T1 
falha e precisa 
mudar o valor 
de X de volta a 
seu valor 
antigo; 
enquanto isso, 
T2 leu o valor 
temporário 
incorreto de X
14
Controle de concorrência
• Problema do sumário/resumo incorreto
– Se uma transação está calculando uma 
função de resumo de agregação em uma 
série de itens de Banco de Dados, enquanto 
outras transações estão atualizando alguns 
desses itens, a função de agregação pode 
calcular alguns valores antes que sejam 
atualizados e outros, depois que eles forem 
atualizados
15
Controle de concorrência
T3 lê X depois 
que N é 
subtraído e lê Y 
antes que N seja 
somado; um 
resumo errado é 
resultado 
(defasado por N)
16
Controle de concorrência
• Problema da leitura não repetitiva
– Uma transação T lê o mesmo item duas vezes e 
o item é alterado por outra transação T’ entre as 
duas leituras
– Logo, T recebe valores diferentes para suas duas 
leituras do mesmo item
– Se durante uma transação de reserva aérea, um 
cliente consultar a disponibilidade de assento em 
vários voos. Quando o cliente decide sobreo um 
voo em particular, a transação lê o número de 
assentos nesse voo pela segunda vez antes de 
completar a reserva, e pode acabar lendo um 
valor diferente para o item
17
Recuperação
• Quando uma transação é enviada ao SGBD 
para execução, o sistema é responsável por 
garantir que:
– Todas as operações na transação sejam concluídas 
com sucesso e seu efeito seja registrado 
permanentemente no BD, ou
– Que a transação não tenha qualquer efeito no Banco 
de Dados ou quaisquer outras transações
• O SGBD não pode permitir que certas 
operações de uma transação sejam aplicadas 
ao Banco de Dados enquanto outras não o são
– A transação inteira é uma unidade lógica de 
processamento
18
Recuperação
• Tipos de falhas
– Falha do sistema/computador (system crash): hardware, 
software ou rede
– Erro no processamento da transação: overflow, divisão por zero, 
interrupção provocada pelo usuário, parâmetros errôneos
– Erros locais ou exceções: dados não encontrados, disco cheio
– Imposição de controle de concorrência: o controle de 
concorrência pode forçar um abort na transação, para posterior 
reinicialização
– Falha do disco: problema físico em uma unidade de disco/blocos
– Problemas físicos e catástrofes: Falha de energia, roubo, 
incêndio, sabotagem, etc...
• No caso dos primeiros quatro motivos (mais comuns), o 
sistema deve manter dados suficientes para permitir a 
recuperação da situação de falha
19
Conceitos de Transações
• Estados de uma transação
• Log do sistema
• Ponto de commit
20
Estados da Transação
• Uma transação é uma unidade atômica de trabalho, 
que deve ser concluída totalmente ou não deve ser 
feita de forma alguma
• Se alguma operação contida na transação tiver 
causado efeito sobre o estado do Banco de Dados, 
o sistema de recuperação deve ser capaz de 
desfazer esse efeito
• Para isso, o sistema de recuperação mantém 
controle dos estados de desenvolvimento das 
transações
• Para fins de recuperação, o sistema precisa 
registrar quando cada transação começa, termina e 
confirma ou aborta
21
Estadosda Transação
• Operações/eventos acompanhados:
– BEGIN_TRANSACTION: marco do início da execução da 
transação
– READ ou WRITE: operações sobre itens do Banco de Dados
– END_TRANSACTION: marco do término da transação, quanto a 
operações sobre o BD; nesse ponto, é preciso determinar se os 
efeitos da transação podem ser aplicados sobre o BD 
permanentemente (committed) ou se a transação deve ser 
abortada (aborted)
– COMMIT_TRANSACTION: sinaliza que a execução foi bem 
sucedida e que os efeitos devem ser mantidos 
permanentemente
– ROLLBACK (ou ABORT): sinaliza que a execução não foi bem 
sucedida, e que qualquer ação precisa ser revertida
22
Estados da Transação
• Ao ser iniciada, a transação se torna ativa
• Ao ser concluída, porém antes de ser confirmada, a 
transação entra no estado de commit parcial (partially 
committed) ou parcialmente confirmada
– Nesse ponto, os protocolos de recuperação precisam garantir que 
os efeitos da transação ainda não se tornaram permanentes
• Quando a verificação final tiver sido concluída, a transação 
entra no estado de commit (committed)
• Quando a verificação final tiver falhado, a transação entra no 
estado de falha (failed)
– Transações que falharam podem ser ressubmetidas pelo usuário ou 
reinicializadas (restarted) pelo próprio sistema como novas 
transações
• Quando a transação sai do sistema, ela entra no estado 
terminado
23
Diagrama de transição de estados para 
execução da transação
24
O Log do sistema
• O principal instrumento para recuperação após 
falhas em transações é o log do sistema
– Log vem de log book, “diário de bordo”
• O log é sempre mantido em disco, para que não 
seja afetado por qualquer tipo de falha, exceto 
catástrofes ou falhas de disco
– O log é sempre copiado para fita ou outro dispositivo 
de backup para prevenir a perda de dados em caso 
de falhas catastróficas
• O sistema mantém um log para registrar todas 
as operações de transação que afetam os 
valores os itens de Banco de Dados
25
O Log do sistema
• Entradas no log (log records)
– [start_transaction, T]
– [write_item, T, X, valor_antigo, 
valor_novo] (X é o item do BD envolvido)
– [read_item, T, X]
– [commit, T]
– [abort, T]
• Quase todos os protocolos evitam 
rollbacks em cascata ou propagação de 
rollbacks
26
O Log do sistema
• Percebe-se que não é exigido que as 
operações READ sejam gravadas no log, 
porém, se esse for usado para outras 
finalidades, pode ser necessário
– Exemplo: auditoria (mantendo registro de 
todas as operações do Banco de Dados)
27
O Log do sistema
• Assumindo que todas as modificações do BD 
ocorram em transações, a recuperação de uma 
falha na transação corresponde a desfazer ou a 
refazer operações individualmente com base no 
log
– Desfazer significa recuar no log ao longo do tempo, 
restabelecendo os valores que tiverem sido alterados 
com write
– Refazer pode ser necessário se não houver a certeza 
de que todas as operações registradas no log 
chegaram de fato a ser executadas sobre o BD
28
Ponto de Commit
• Uma transação atinge o ponto de commit (ou 
ponto de confirmação) quando
– Todas as operações que acessam o BD tiverem sido 
executadas com sucesso
– E o efeito de todas as operações foi registrado no log
• Depois de atingir o ponto de commit, diz-se que 
a transação foi concluída (committed) quando 
seu efeito foi permanentemente registrado no 
BD
– É aí que uma entrada [commit, T] é gravada no 
log
29
Ponto de Commit
• Se ocorrer uma falha, o log é vasculhado em 
busca de transações para as quais existe um 
[start_transaction, T] e não existe um 
[commit, T] correspondente
• Tais transações têm que sofrer um rollback 
(serão descartadas)
• Ao gravar o [commit, T] no log, a transação 
garantidamente já fez todos os seus writes e os 
correspondentes registros no log, de modo a 
possibilitar a reexecução da transação em caso 
de falha posterior
30
Ponto de Commit
• É comum que alguns registros de log sejam 
mantidos em memória até encher um bloco para 
gravação no disco (usa o buffer de log)
• Em caso de falha, esses registros serão 
perdidos, e portanto as transações 
correspondentes terão que sofrer rollback 
mesmo tendo sido concluídas
• Portanto, antes que uma transação atinja o 
ponto de commit, todos os writes, inclusive os 
dos registros de log, têm que ter sido realizados
– Force-writing do log para o disco
31
Propriedades de Transações
• As principais propriedades das transações são chamadas de 
ACID:
– Atomicidade
• A transação é uma unidade de processamento atômica; ela deve ser 
realizada em sua totalidade ou não ser realizada de forma alguma
– Consistência (preservação da consistência)
• Se a transação for completamente executada do início ao fim sem 
interferência de outras, deve levar o BD de um estado consistente para 
outro
– Isolamento
• Uma transação não deve sofrer a interferência nem interferir em outras 
transações que estejam sendo executadas simultaneamente
– Durabilidade (persistência ou permanência)
• As mudanças provocadas no BD por uma transação que atingiu o ponto 
de commit devem ser persistentes, e não podem ser perdidas devido a 
nenhum tipo de falha
32
Escalonamentos (schedules)
• O escalonamento, histórico ou schedule é 
a ordem de execução das operações das 
várias transações que estão em execução 
concorrente
• Existem tipos de escalonamentos que 
facilitam a recuperação em caso de 
falhas, e outros que minimizam a 
interferência entre transações 
(escalonamentos serializáveis)
33
Escalonamentos (schedules)
• Notação:
– Sa: Plano de execução de transações
– r1(X): Transação 1 deseja ler o item X
– w2(X): Transação 2 deseja escrever no item X
– a1: Operação abort na transação 1
– c1: Operação commit na transação 1
– b1: begin_transaction 1
– e1: end_transaction 1
34
Notação de escalonamento
Item X tem um 
valor incorreto 
porque sua 
atualização 
por T1 é 
perdida 
(sobrescrita)
• Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);
35
Notação de escalonamento
Transação T1 
falha e precisa 
mudar o valor 
de X de volta a 
seu valor 
antigo; 
enquanto isso, 
T2 leu o valor 
temporário 
incorreto de X
• Sb: r1(X); w1(X); r2(X); w2(X); r1(Y); a1;
36
Escalonamentos (schedules)
• Duas operações em um schedule estão em 
conflito quando as seguintes três condições 
ocorrem simultaneamente:
– Elas pertencem a transações diferentes
– Elas acessam o mesmo item
– Pelo menos uma delas é um write
• No primeiro exemplo, r1(X) e w2(X) estão em 
conflito
• Também estão em conflito r2(X) e w1(X)
• As demais operações não estão em conflito
37
Escalonamentos (schedules)
• Um escalonamento S contendo n transações T1, 
T2,... Tn é dito completo se as seguintes 
condições forem observadas:
1. As operações em S são exatamente as mesmas 
contidas em T1, T2,... Tn, incluindo uma operação 
commit ou abort como última operação em cada 
transação do schedule
2. Para qualquer par de operações da mesma transação 
Ti, a ordem em que aparecem em S é a mesma em 
que aparecem em Ti
3. No caso de quaisquer duas operações em conflito, 
uma deve ocorrer antes da outra no escalonamento
38
Escalonamentos (schedules)
• Como a condição (3) não exige que seja 
estabelecida uma ordem fixa para 
operações que não estejam em conflito, 
podem existir escalonamentos de 
ordenamento parcial
– A ordenação total deve ser especificada 
apenas entre operações da mesma transação 
e entre operações em conflito
39
Escalonamentos (schedules)
• É raro encontrar escalonamentos totais na 
prática, pois novas transações são 
iniciadas continuamente
– Isso motiva a definição de projeção decommit, C(S), que inclui apenas as operações 
de S que pertencem a transações committed, 
ou seja, transações Ti para as quais uma 
operação ci tenha sido incluída em S
40
Caracterização de Escalonamentos
• Com base na possibilidade de recuperação
– Escalonamentos recuperáveis: transações que atingiram o 
ponto de commit nunca devem precisar de rollback
– Escalonamentos não recuperáveis
• Um escalonamento S é recuperável se nenhuma 
transação T de S atinge o ponto de commit até que 
todas as transações T’ que gravam algum item, que 
é lido em T, tenham também atingido o ponto de 
commit
– Ou seja, é preciso garantir que T’ não seja abortada antes 
de permitir que T faça uso do item que tem que ser lido
– Sa e Sb são recuperáveis
41
Caracterização de Escalonamentos
Recuperação
• Escalonamentos não recuperáveis:
– Sa’: r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1
• Idem ao Sa, porém incluindo commits 
– Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1
• Não recuperável, pois T2 lê X, que é modificado por T1, 
e executa commit antes de T1; quando T1 é abortada, 
T2 precisa voltar atrás depois de ter sido committed
• Para que esse plano seja recuperável, o commit de T2 
deve ser adiado até que T1 tenha sido committed
– Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2
• Caso T1 aborte, T2 tem que abortar também
42
Caracterização de Escalonamentos
Recuperação
• Em um escalonamento recuperável, nenhuma 
transação committed precisa sofrer rollback
• É possível, no entanto, que transações não 
committed provoquem um rollback em cascata 
(cascading rollback)
– Ocorre quando uma transação lê um valor alterado 
anteriormente por uma transação que falhou, e isso 
pode acontecer em diversos níveis aninhados
– No exemplo, em Se a transação T2 precisa sofrer 
rollback porque a transação T1 falhou
• Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2
43
Caracterização de Escalonamentos
Recuperação
• Como o rollback em cascata (ou propagação de 
cancelamento) pode consumir muito tempo, é 
importante caracterizar os escalonamentos onde 
isso garantidamente não pode acontecer
– Escalonamentos cascadeless: cada transação no 
schedule lê apenas itens que foram gravados por 
transações committed
• No exemplo, o comando r2(X) dos planos Sd e Se 
precisa ser adiado até que T1 seja committed ou 
abortada
– Isso causa atraso em T2 mas evita o cascading 
rollback
44
Caracterização de Escalonamentos
Recuperação
• Escalonamento estrito (strict)
– Transações não podem ler nem gravar itens 
até que a última transação que gravou o item 
seja committed ou abortada, dando acesso 
exclusivo à transação que gravou o item
– Este tipo de escalonamento simplifica o 
tratamento de recuperação, pois só o que o 
rollback precisa fazer é restaurar o valor 
anterior do item, de acordo com o log
• Isso não funciona sempre no caso de 
escalonamento recuperável ou cascadeless
• Log de exemplo: Sf: w1(X, 5); w2(X, 8); a1;
45
Caracterização de Escalonamentos
Serialização
• Com base na serialização
– Alguns escalonamentos só podem ser considerados 
corretos se as transações forem executadas em 
sequência, sem que as operações internas a elas 
sejam intercaladas
– Exemplo: reserva de passagens aéreas
– Se o SGBD receber as transações T1 e T2 
aproximadamente juntas, pode ser necessário 
executar T1 totalmente, e depois T2, ou vice-versa
– O problema é determinar que escalonamentos estão 
corretos mesmo quando a execução das operações é 
intercalada
46
Caracterização de Escalonamentos
Serialização
Escalonamentos seriais
47
Caracterização de Escalonamentos
Serialização
Escalonamentos não-seriais
48
Caracterização de Escalonamentos
Serialização
• Um escalonamento S é dito serial se, para cada 
transação T incluída nele, todas as operações de T 
forem executadas consecutivamente
• Se houver intercalação, o escalonamento é dito 
não-serial
• Num escalonamento serial, apenas uma transação está 
ativa em um determinado instante
– O commit ou abort desta transação dispara a seguinte
• Se as transações forem independentes (I do ACID), todo 
escalonamento serial é considerado correto (já que se 
assume que as transações são consistentes – C do 
ACID)
– Portanto, a ordem de execução das transações não importa
49
Caracterização de Escalonamentos
Serialização
• O problema com escalonamentos seriais é 
a limitação da concorrência e do 
entrelaçamento das operações, o que 
causa atrasos no processamento
– As operações podem ser forçadas a esperar 
por acessos a disco
– Transações de mais longa duração podem 
causar grandes latências em transações 
subsequentes
– Na prática, esses atrasos são inaceitáveis
50
Caracterização de Escalonamentos
Serialização
•Um escalonamento S com n operações é dito serializável 
se ele for equivalente a algum escalonamento serial 
envolvendo as mesmas n operações
– Escalonamentos são equivalentes de acordo com dois critérios
•Equivalentes quanto aos resultados: produzem o mesmo estado 
final para o Banco de Dados;
– obs: o resultado pode ser acidentalmente igual; esse 
critério não é suficiente
•Equivalentes quanto aos conflitos: a ordem entre duas 
operações em conflito quaisquer é a mesma em ambos os 
escalonamentos; este critério é o mais usado
– Se o escalonamento é serializável, ele é correto, pois seus 
resultados são equivalentes aos de um escalonamento serial
51
Caracterização de Escalonamentos
Serialização
S1 S2
read_item(X); read_item(X);
X:=X+10; X:=X*1.1;
write_item(X); write_item(X);
Os planos de execução acima são 
equivalentes, uma vez que produzem o 
mesmo resultado, quando X=100?
52
Caracterização de Escalonamentos
Serialização
• Se um escalonamento é equivalente quanto a 
conflitos a um serial, ele é dito serializável por 
conflito
• Neste caso, pode-se reordenar as operações 
não conflitantes do escalonamento serial até 
formar o equivalente serializável por conflito
• Existe um algoritmo para determinar se 
escalonamentos são serializáveis por conflito
– Usa grafos de precedência
53
Algoritmo de teste de conflito de 
serialidade
1. Para cada transação Ti participante do 
plano S, crie um nó rotulado Ti no grafo 
de precedência
T1 T2
54
Algoritmo de teste de conflito de 
serialidade
2. Para cada caso em S em que Tj executar um 
read_item(X) depois que uma Ti executar 
write_item(X), criar uma seta (Ti Tj) no 
grafo de precedência
T1 T2
X
55
Algoritmo de teste de conflito de 
serialidade
3. Para cada caso em S que Tj executar 
write_item(X) depois que Ti executar um 
read_item(X), criar uma seta (Ti Tj) no 
grafo de precedência
T1 T2
X
56
Algoritmo de teste de conflito de 
serialidade
4. Para cada caso em S que Tj executar 
write_item(X) depois que Ti executar um 
write_item(X), criar uma seta (Ti Tj) no 
grafo de precedência
T1 T2
X
57
Algoritmo de teste de conflito de 
serialidade
5. O plano S será serializável se, e apenas 
se, o grafo precedência não contiver 
ciclos
T1 T2
X
É serializável
58
Algoritmo de teste de conflito de 
serialidade
T1 T2
X
É serializável
59
Algoritmo de teste de conflito de 
serialidade
T1 T2
X
Não é serializável
X
60
Algoritmo de teste de conflito de 
serialidade
T1 T2
X
É serializável
61
Caracterização de Escalonamentos
Serialização
• Usos da “serializabilidade” (ou “seriabilidade”)
– Obs: Escalonamentos serializáveis não são seriais; o 
entrelaçamento das operações é importante para garantir 
desempenho
– Se as transações forem executadas aleatoriamente e o 
escalonamento resultante for testado para verificar seé 
serializável, todos os efeitos de todas as transações deverão ser 
cancelados se o resultado for negativo
– O enfoque adotado na prática consiste em determinar métodos 
de escalonamento que garantam a serialização, sem que seja 
necessário testar a posteriori
• SGBD implementam protocolos que devem ser seguidos por todas 
as transações e pelo subsistema de controle de concorrência, e que 
garantem que todos os escalonamentos em que essas transações 
participarem serão serializáveis
62
Caracterização de Escalonamentos
Serialização
• Quando o SGBD recebe transações 
continuamente, é difícil definir quando começa e 
quando termina um escalonamento
– O algoritmo é adaptado para funcionar com a 
projeção de commit do escalonamento, i.e., 
considerando apenas as operações que pertencem a 
transações committed
– Um escalonamento S é serializável se sua projeção 
de commit for equivalente a algum escalonamento 
serial
– Técnicas de controle de concorrência lidam com a 
seriabilidade usando travamentos, como o two-phase 
locking ou outros protocolos
63
Suporte a Transações em SQL
• Existem condições em que o início e o fim da 
transação estão implícitos na execução de um 
comando SQL
• O comando SET TRANSACTION define 
parâmetros para a execução
– Modo de acesso: READ ONLY ou READ WRITE
– Tamanho da área de diagnóstico: DIAGNOSTIC SIZE 
n (número de condições de erro/violações 
acompanhadas simultaneamente)
– Nível de isolamento: ISOLATION LEVEL <valor>, que 
pode ser READ UNCOMMITTED, READ 
COMMITTED, REPEATABLE READ ou 
SERIALIZABLE (default)
64
Suporte a Transações em SQL
• Violações
– Dirty Read: uma transação T1 pode ler um valor 
gravado pela transação T2, mas T2 ainda não foi 
committed; se T2 falhar, T1 teria lido um valor 
incorreto
– Nonrepeatable Read: uma transação T1 pode ler um 
valor de uma tabela; se outra transação T2 alterar o 
valor, e T1 for então ler a mesma tabela novamente, 
encontrará um valor diferente
– Phantom: uma transação T1 pode ler um conjunto de 
linhas de uma tabela, possivelmente com base em 
uma cláusula de seleção; T2 insere outra linha na 
tabela que também atenda à condição de seleção; se 
T1 for repetida, enxergará um “fantasma”, uma linha 
que não existia anteriormente
65
Tópicos Finais
Tipo de violação
Nível de isolamento Dirty read Nonrepeatable read Phantom
READ 
UNCOMMITTED Yes Yes Yes
READ 
COMMITTED No Yes Yes
REPEATABLE 
READ No No Yes
SERIALIZABLE No No No
66
Bibliografia
• Capítulo 21: Elsmari Ramez; Navathe 
Shamkant B. Sistemas de Banco de 
Dados – Fundamentos e Aplicações. 6 ed. 
Pearson, São Paulo, 2011.