Banco de Dados - Transações

Prévia do material em texto

Banco de Dados 
 
 
Transações 
 
 
 
Profa. Leticia Zoby 
Introdução 
• Sistema Gerenciador de Banco de Dados – SGBD 
• O que é o SGBD? 
• Quais funcionalidades? 
 
Arquitetura de um SGBD 
4 
Introdução ao processamento de Transações 
• Um dos critérios de classificação para SGBDs é em relação 
ao número de usuários que podem usá-los ao mesmo 
tempo: 
• Monousuário: apenas um usuário pode utilizar o sistema em 
um momento; 
• Sistemas de BD que são projetados para uso em um micro-
computador; 
• Multiusuário: vários usuários podem utilizar o sistema em um 
momento. 
• Sistemas de reserva de passagens aéreas; 
• Sistemas bancários/financeiros; 
• Sistemas de venda para WEB. 
5 
Introdução ao processamento de Transações 
• SGBDs são em geral multi-usuários 
• processam simultaneamente operações disparadas por 
vários usuários 
• deseja-se alta disponibilidade e tempo de resposta pequeno 
• execução intercalada de conjuntos de operações 
• exemplo: enquanto um processo i faz I/O, outro processo j é 
selecionado para execução 
Tempo t1 t1 t3 t4 
A A 
B B 
C 
D 
Execução entrelaçada Execução paralela 
6 
O Conceito de Transação 
• Um conjunto de várias operação em um BD pode ser visto 
pelo usuário como uma única unidade. 
• Exemplo: A transferência de fundos de uma conta corrente 
pra uma conta poupança é uma operação única do ponto de 
vista do cliente, porém, dentro do sistemas de banco de 
dados, ela envolve várias operações. 
• É essencial que todo o conjunto de operações seja 
concluído, ou que, no caso de uma falha, nenhuma delas 
ocorra. 
• Essas operações, que formam uma única unidade lógica 
de trabalho são chamadas de transações. 
 
7 
O Conceito de Transação 
• Uma transação é uma unidade lógica de 
processamento de banco de dados 
• Composta de uma ou mais operações 
• Seus limites podem ser determinados em SQL 
• Durante a execução de uma transação o BD pode estar 
inconsistente 
• De forma simplificada, uma transação pode ser encarada 
como um conjunto de operações de leitura e escrita de 
dados 
 
 
read(x) 
x = x – i 
read(y) 
y = y * x 
write(x) 
write(y) 
Tx 
lê o dado X do BD e o 
armazena na variável X 
grava no dado Y do BD o 
valor da variável Y 
O Conceito de Transação 
• Uma transação é uma unidade da execução de um 
programa que acessa e possivelmente atualiza vários 
itens de dados (Kort, 2006). 
• Abstração que representa a sequência de operações de 
bancos de dados resultantes da execução de um 
programa (Eswaram et al). 
 
• Exemplo: Transferência Bancária 
• Retirar dinheiro de uma conta origem 
• Verificar saldo 
• Subtrair o valor do depósito da conta de origem 
• Atualizar o saldo 
• Depositar na conta destino 
• Ler saldo 
• Somar o valor do saldo na conta destino 
• Atualizar o saldo 
 
9 
Motivação 
• Origem 
• aplicações comerciais e financeiras 
• Características das aplicações-alvo 
• curta duração 
• tipos de dados restritos 
• tipos de operações restritos 
• Problemas 
• compartilhamento de dados 
• ocorrência de falhas 
10 
Desafios 
• Questões principais devem ser tratadas 
• Falhas de diversos tipos, tais como falhas de hardware e 
quedas de sistema 
• Execução concorrente de múltiplas transações 
• Exemplo 
Transação para transferir $ 50 da conta A para conta B 
 
1. Read (A) 
2. A = A – 50 
3. Write (A) 
4. Read (B) 
5. B = B + 50 
6. Write (B) 
11 
Propriedades de uma Transação (ACID) 
• Requisitos que sempre devem ser atendidos por 
uma transação 
• Chamadas de propriedades ACID 
 
12 
Atomicidade 
• Princípio do “Tudo ou Nada” 
 
 
 
 
 
 
Ou todas as operações de uma transação 
são efetivadas com sucesso no BD ou 
nenhuma delas se efetiva 
13 
Consistência 
• Uma transação sempre conduz o BD de um estado 
consistente para outro estado também consistente 
• Durante a execução da transação, a base de dados pode 
passar por um estado inconsistente 
• Responsabilidade conjunta do 
• DBA 
• definir todas as RIs para garantir estados e transições de estado 
válidos para os dados 
• Sistema de recovery 
• desfazer as ações da transação que violou a integridade 
 
14 
Isolamento 
 
• A execução de uma transação Tx deve funcionar 
como se Tx executasse de forma isolada 
• Tx não deve sofrer interferências de outras transações 
executando concorrentemente 
• Resultados intermediários das transações devem ser 
escondidos de outras transações executadas 
concorrentemente 
• Responsabilidade do subsistema de controle de 
concorrência (scheduler) do SGBD 
15 
Isolamento 
T1 T2 
read(A) 
A = A – 50 
write(A) 
read(A) 
A = A+A*0.1 
write(A) 
read(B) 
B = B + 50 
write(B) 
read(B) 
B = B - 100 
write(B) 
T1 T2 
read(A) 
A = A – 50 
read(A) 
A = A+A*0.1 
write(A) 
read(B) 
write(A) 
read(B) 
B = B + 50 
write(B) 
B = B - 100 
write(B) 
escalonamento válido escalonamento inválido 
T1 interfere 
em T2 
T2 interfere 
em T1 
16 
Durabilidade 
 
• Deve-se garantir que as modificações realizadas 
por uma transação que concluiu com sucesso 
persistam no BD 
• nenhuma falha posterior ocorrida no BD deve perder 
essas modificações 
• Responsabilidade do subsistema de recovery 
• refazer transações que executaram com sucesso em caso de 
falha no BD 
 
17 
Exemplo 
• Transação: aplicação financeira 
 Read(Conta); 
 Conta.Saldo = Conta.Saldo – 100; 
 Write(Conta); 
 Read (Aplicação); 
 Aplicação.Saldo = Aplicação.Saldo + 100; 
 Write (Aplicação); 
 
• Aplicação das propriedades ACID: 
• Atomicidade: faz todas as operações ou nenhuma 
• Consistência: deve manter o saldo total do cliente 
• Isolamento: controla as operações concorrentes 
• Durabilidade: salva as modificações no BD 
18 
Exemplo 
• Transação para transferir $ 50 da conta A para conta B 
1. Read (A) 
2. A = A – 50 
3. Write (A) 
4. Read (B) 
5. B = B + 50 
6. Write (B) 
• Requisito de Consistência 
– A soma de A e B não se altera pela execução da transação. 
• Requisito de Atomicidade 
– Se a transação falhar após o passo 3 e antes do passo 6, o sistema deve 
assegurar que as suas atualizações não sejam refletidas no banco de dados. 
• Requisito de Durabilidade 
– Uma vez que o usuário tenha sido notificado que a transação foi completada (ou 
seja, a transferência dos $50 ocorreu), as atualizações no banco de dados feitas 
pela transação devem persistir, mesmo na ocorrência de falhas 
• Requisito de Isolamento 
– Se, entre os passos 3 e 6, outra transação tiver permissão para acessar o banco 
de dados parcialmente atualizado, ela verá um banco de dados inconsistente (a 
soma A + B valerá menos do que deveria) 
19 
Operações 
• Begin_Transaction: início da execução da transação 
• Read/Write: especifica operações de leitura ou escrita de 
itens do BD que são executadas como parte da transação -> 
(acesso ao banco) 
• End_Transaction: especifica que as operações terminaram e 
marca o limite final da transação 
• Commit_Transaction (validação): sinaliza o final com 
sucesso de uma transação de modo que qualquer 
atualização executada pela transação possa ser efetivada 
no BD 
• Rollback (abort): sinaliza que a transação terminou sem 
sucesso e o que foi executado deve ser desfeito 
 
20 
Estados de uma Transação 
• Uma transação é sempre monitorada pelo SGBD quanto ao 
seu estado 
• que operações já fez? concluiu suas operações? deve abortar? 
 
•Quando uma transação é executada, o sistema deve 
garantir: 
• Todas as transações foram completadas com sucesso, o sistema 
deve gravar permanentemente os dados no BD; 
• Ou a transação não terá nenhum efeito sobre o BD, quando detectar 
uma FALHA. 
• Tipos de falhas: 
• Computador falhar, como queda no sistema; 
• Erro de transação no sistema, como overflow; 
• Falhas de disco; 
• Problemas físicos e catástrofes. 
 
21 
Estados de uma Transação 
• Estados de uma transação 
• Ativa – poderá emitir operações de read e write; 
• Em processo de efetivação (ou parcialmente efetivada) – alguns 
protocolos de restauração precisam garantir que uma falha de 
sistema não impossibilite a gravação permanente dos dados 
(gravada no logs); 
• Efetivada (committed state) - uma vez atendida todas as 
verificações; 
• Em processo de aborto (ou falha) - se uma das verificações falhar ou 
se a transação for interrompida em seu estado ativo. A transação 
deverá ser revertida para desfazer os efeitos das operações de 
WRITE no BD e; 
• Concluída (ou encerrada) - quando a transação deixa o sistema. 
 
22 
Transição de Estados de uma Transação 
Ativa 
Em Processo 
de Efetivação 
Efetivada 
Em Processo 
de Aborto 
Concluída 
iniciar 
transação 
finalizar 
transação 
transação deve 
ser desfeita 
 conclusão 
da transação 
com sucesso 
encerramento 
com sucesso 
 
conclusão 
da transação 
sem sucesso 
reads e writes 
encerramento 
sem sucesso 
 
23 
Transição de Estados de uma Transação 
Ativa 
Em Processo 
de Efetivação 
Efetivada 
Em Processo 
de Aborto 
Concluída 
iniciar 
transação 
finalizar 
transação 
transação deve 
ser desfeita 
conclusão 
da transação 
com sucesso 
encerramento 
com sucesso 
conclusão 
da transação 
sem sucesso 
transação deve 
ser desfeita 
• estado inicial de toda 
transação selecionada 
para execução 
• enquanto ativa, uma 
transação executa uma ou 
mais operações read e write 
reads e writes 
24 
Transição de Estados de uma Transação 
encerramento 
sem sucesso Ativa 
Em Processo 
de Efetivação 
Efetivada 
Em Processo 
de Aborto 
Concluída 
iniciar 
transação 
finalizar 
transação 
transação deve 
ser desfeita 
conclusão 
da transação 
com sucesso 
encerramento 
com sucesso 
conclusão 
da transação 
sem sucesso 
reads e writes 
• entra nesse estado após 
executar sua última operação 
• neste momento, o SGBD 
precisa garantir que as suas 
atualizações sejam efetivadas 
com sucesso (não sofra falhas) 
– aplicação de técnicas de 
recovery 
25 
Transição de Estados de uma Transação 
Ativa 
Em Processo 
de Efetivação 
Efetivada 
Em Processo 
de Aborto 
Concluída 
iniciar 
transação 
finalizar 
transação 
transação deve 
ser desfeita 
conclusão 
da transação 
com sucesso 
encerramento 
com sucesso 
conclusão 
da transação 
sem sucesso 
reads e writes 
• entra nesse estado após o 
SGBD confirmar que todas as 
modificações da transação estão 
garantidas no BD (COMMIT) 
– exemplos: gravação em Log, 
descarga dos buffers 
em disco 
encerramento 
sem sucesso 
26 
Transição de Estados de uma Transação 
Ativa 
Em Processo 
de Efetivação 
Efetivada 
Em Processo 
de Aborto 
Concluída 
iniciar 
transação 
finalizar 
transação 
transação deve 
ser desfeita 
conclusão 
da transação 
com sucesso 
encerramento 
com sucesso 
conclusão 
da transação 
sem sucesso 
reads e writes 
• entra nesse estado se não puder 
prosseguir a sua execução 
• pode passar para esse estado enquanto 
ativa (I) ou em processo de efetivação (II) 
– exemplo (I): violação de RI 
– exemplo (II): pane no S.O. 
 suas ações já realizadas devem ser desfeitas 
 (ROLLBACK) 
encerramento 
sem sucesso 
27 
Transição de Estados de uma Transação 
encerramento 
sem sucesso Ativa 
Em Processo 
de Efetivação 
Efetivada 
Em Processo 
de Aborto 
Concluída 
iniciar 
transação 
finalizar 
transação 
transação deve 
ser desfeita 
conclusão 
da transação 
com sucesso 
encerramento 
com sucesso 
conclusão 
da transação 
sem sucesso 
reads e writes 
• estado final de uma transação 
• indica uma transação que deixa o 
sistema 
– as informações da transação 
mantidas em catálogo podem ser 
excluídas 
 operações feitas, dados 
manipulados, buffers utilizados, ... 
– se a transação não concluiu com 
sucesso, ela pode ser reiniciada 
automaticamente 
28 
Gerência Básica de Transações 
T1 inicia 
Ações da Aplicação ou Usuário Ações do SGBD 
inicia ações para 
garantir Atomicidade de T1 T1 submete 
operações DML executa operações DML, 
garantindo Isolamento de 
T1, e testa RIs imediatas, 
com possível rollback e 
msg erro, para garantir 
Consistência de T1 
T1 termina 
testa RIs postergadas, 
com possível rollback e 
msg erro, para garantir 
Consistência de T1 
executa ações para 
garantir Durabilidade de T1 
confirma o término de T1 
para a aplicação/usuário 
29 
O Log do Sistema 
 
• Utilizado para permitir recuperação de falhas de 
transações. 
• Também chamado de Journal 
• Registra todas as operações que afetam valores de itens 
do BD 
• Guardado em disco 
• Periodicamente copiado para um sistema de 
armazenamento (backup). 
 
30 
O Log do Sistema 
• Tipos de entradas no Log 
• [start_transaction, T] 
• [write_item, T, X, old-value, new-value] 
• [read_item, T, X] 
• [commit, T] 
• [abort, T] 
 
31 
Ponto de Efetivação 
• Uma transação T alcança seu ponto de efetivação 
(commit point) quando 
• Todas as suas operações que acessam o banco de 
dados estão sendo executadas com sucesso e; 
• O efeito de todas elas estiverem sendo gravados no 
log. 
• Após o ponto de efetivação, a transação é dita 
efetivada e seu efeito será gravado de modo 
permanente no BD. 
• Gravação forçada (force-writting) 
32 
Gerenciamento 
 
• Commit Point 
• Quando todas as operações que acessam o BD foram 
executadas com sucesso e o efeito de todas as 
operações da transação no BD já foram gravadas no 
log 
 
• •Checkpoints no Log do Sistema 
• Escritos no log periodicamente quando o sistema grava 
no disco todas as operações WRITE de transações 
efetivadas 
33 
Checkpoints no Log do Sistema 
• O gerenciamento de recuperação do SGBD deve 
decidir quais os intervalos em que devem ocorrer 
checkpoints 
• Em unidade de tempo 
• Em número de transações efetivadas após o último 
checkpoint 
 
34 
Ações de um checkpoints 
 
• Suspender temporariamente a execução de 
transações 
• Forçar a escrita de todas as operações de 
modificação das transações efetivadas do buffer no 
disco 
• Escrever um registro [checkpoint] no log e forçar a 
escrita do log no disco 
• Voltar à execução de transações 
 
 
 
 
 
 
 
 
35 
Escalonamento ou História de Transações 
 
• A ordem de execução das operações de várias transações 
executando concorrentemente na forma intercalada é 
conhecida como: 
• Plano de execução 
• Baseados na Restaurabilidade 
• Baseados em Serialidade 
36 
Plano de Execução de Transações 
 
• Definição formal: 
• Um plano (ou histórico) S de n transações T1, T2, ... , Tn 
é a ordenação das operações das transações sujeitas a 
uma restrição 
• Para cada Ti que participe de S, as operações de Ti em 
S deverãoaparecer na mesma ordem em que elas 
ocorrem em Ti. 
 
 
 
 
 
37 
Plano de Execução de Transações 
• Operações em conflito 
• Duas operações são ditas em conflito se elas satisfazem 
todas as três condições seguintes: 
 1.Pertencerem a transações diferentes 
 2.Acessarem o mesmo item X 
 3.Pelo menos uma das operações ser um 
escrever_item(X). 
 
 Ex: 
 
38 
Plano de Execução de Transações 
• Operações em conflito 
1.Pertencerem a transações diferentes 
2.Acessarem o mesmo item X 
 3.Pelo menos uma das operações ser um escrever_item(X). 
 Ex: 
 
39 
Plano de Execução de Transações 
• Plano Completo 
• Um plano S, com n transações T1, T2, ... ,Tn é chamado 
um plano completo se forem garantidas as seguintes 
condições: 
• As operações em S são exatamente as operações de 
T1, T2, ..., Tn, tendo um commit ou um abort como última 
operação de cada transação no plano. 
• Para quaisquer pares de operações da mesma operação 
Ti, sua ordem de aparecimento em S será a mesma de 
Ti 
• Para quaisquer duas operações conflitantes, uma das 
duas precisa aparecer antes da outra no plano. 
 
40 
Plano de Execução de Transações 
• Plano restauráveis e não restauráveis 
 
• Restauráveis 
• É aquele na qual, para cada par de transações Ti e 
Tj, tal que Tj leia itens de dados previamente escritos 
por Ti, a operação de efetivação de Ti apareça 
antes da operação de efetivação de Tj. 
 
 
Uma vez efetivada uma transação T, nunca mais seja necessário revertê-la. 
41 
Plano de Execução de Transações 
• Plano restauráveis e não restauráveis 
• Exemplo: 
 
42 
Plano de Execução de Transações 
• Reversão em cascata 
• Uma transação não efetivada tem de ser revertida 
porque leu um item de um transação que falhou. 
• S: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2; 
• Sb: r1(X); w1(X); r2(X); r1(Y); w2(X); c1; c2; Para satisfazer 
esse critério, operação r2(X) desse plano deve ser adiada 
até que T1 seja efetivada (ou abortada). 
• É importante estabelecer planos livres de reversão em 
cascata. 
• Solução: Uma transação somente ler os itens que foram 
gravados por transações efetivadas. 
 
 
43 
Plano de Execução de Transações 
• Plano estrito (strict schedule) 
 
• As transações não poderão nem ler nem gravar um item X 
até a ultima transação que grave X tenha sido efetivada. 
• Simplificam a restauração 
• Desfazer uma operação de escrita de uma transação é 
simplesmente restaurar a imagem anterior. 
 
44 
Plano de Execução de Transações 
• Serialidade (Serializability) 
• Planos seriais 
• As operações de cada transação são executadas 
consecutivamente, sem intercalação das operações de 
outra transação. 
• Apenas uma transação ativa por vez 
• Limitam a concorrência ou intercalação de transações. 
• São inaceitáveis na prática. 
 
• Planos não seriais 
 
• O conceito de serialidade de planos é usado para 
identificar quais planos são corretos quando há 
intercalação das operações das transações na execução 
dos planos 
45 
Plano de Execução de Transações 
• Serialidade (Serializability) 
 
• Considere um sistema de reservas onde T1 e T2 
ocorrem aproximadamente ao mesmo tempo 
 
46 
Plano de Execução de Transações 
• Serialidade (Serializability) 
 
• Se a intercalação de operações não for permitida 
temos as duas opções: 
 
 
47 
Plano de Execução de Transações 
• Serialidade (Serializability) 
 
• Se a intercalação de operações for permitida temos 
diversas opções, como: 
 
 
48 
Plano de Execução de Transações 
• Serialidade (Serializability) 
• Exemplo: 
49 
Plano de Execução de Transações 
• Serialidade (Serializability) 
• Exemplo: 
50 
Plano de Execução de Transações 
• Serialidade (Serializability) 
• Exemplo: 
51 
Plano de Execução de Transações 
• Serialidade (Serializability) 
• Exemplo: 
52 
Plano de Execução de Transações 
• Serialidade (Serializability) 
• Exemplo: 
53 
Plano de Execução de Transações 
• Serialidade (Serializability) 
• Exemplo: 
54 
Plano de Execução de Transações 
• Equivalência de planos 
 
• Dois planos são chamados resultado equivalentes se 
produzirem o mesmo estado final do banco de dados. 
• Para dois planos serem equivalentes, as operações 
aplicadas a cada item de dado afetado por eles devem 
aparecer na mesma ordem em ambos os planos. 
• Equivalência de conflito 
• Se a ordem das operações conflitantes forem a mesma. 
• Equivalência de visão 
 
55 
Plano de Execução de Transações 
• Planos Conflito serializáveis 
 
• Uma plano S com n transações é dito serializável se ele 
for equivalente a algum plano serial com as mesmas n 
transações. 
• Dizer que um plano S não-serial é serializável é o 
mesmo que dizer que ele é correto. 
56 
Plano de Execução de Transações 
• Planos Conflito serializáveis 
57 
Plano de Execução de Transações 
• Testando o conflito serialidade 
• Grafo de precedência 
 
 
 
 
 
 
• Uma seta será criada caso alguma das operações de Tj 
apareça no plano antes de alguma operação conflitante 
de Tk. 
 
58 
Plano de Execução de Transações 
• Algoritmo 
• Para cada transação Ti participante do plano S, criar um nó 
rotulado Ti no grafo de precedência 
• Para cada caso em S em que Tj executar um ler_item(X) 
depois que uma Ti executar um escrever_item(X), criar uma 
seta Ti Tj no grafo de precedência. 
• Para cada caso em S em que Tj executar um 
escrever_item(X) depois que uma Ti executar um 
ler_item(X), criar uma seta Ti Tj no grafo de precedência. 
• Para cada caso em S em que Tj executar um 
escrever_item(X) depois que uma Ti executar um 
escrever_item(X), criar uma seta Ti Tj no grafo de 
precedência. 
• O plano S será serializável se, o grafo de precedência não 
contiver ciclos. 
 
59 
Plano de Execução de Transações 
• Ex: 
60 
Plano de Execução de Transações 
• Ex: 
 
 
 
 
 Não é seriável pois há um ciclo. 
OBS: No grafo deve aparecer apenas um representante dos conflitos entre 
duas transações. 
Por exemplo: entre T1 e T2 temos 3 conflitos: r1(X) com w2(X); w1(X) com 
r2(X) e w1(X) com w2(X), mas apenas um arco é representado no grafo. 
61 
Plano de Execução de Transações 
• Ex: No âmbito de banco de dados, que grafo de 
precedência representa um escalonamento que NÃO é 
serializável quanto ao conflito? 
 
 
62 
Plano de Execução de Transações 
• Aplicação da serialidade 
 
• A abordagem adotada na maioria dos SGBDs comerciais é 
definir protocolos (conjunto de regras) que: 
 
• Devem ser seguidos por todas as transações individualmente, 
ou impostos por um subsistema de controle de concorrência do 
SGBD 
 
• E garantirão a serialidade de todos os planos dos quais as 
transações participam. 
 
63 
Plano de Execução de Transações 
• Equivalência de visão e visão serialidade 
• Diz que dois planos S e S’ são visão equivalente se: 
 
• O conjunto de transações participantes em S e S’ 
seja o mesmo e que S e S’ contenham as mesmas 
operações dessas transações. 
• Para toda operação ri(X) de Ti em S, se o valor X lido 
pela operação tiver sido alterado por uma operação 
wj(X) de Tj, a mesma condição deverá ser garantida 
para o valor X lido pela operação ri(X) de Ti em S’. 
• Se a operação wk(Y) de Tk for a última operação a 
gravar o item Y em S, então wk(Y) de Tk também 
deverá ser a última operaçãoa gravar Y em S’. 
 
64 
Plano de Execução de Transações 
• SUPORTE A TRANSAÇÃO EM SQL 
 
• Transação 
• Uma unidade lógica de trabalho 
• Garantida como atômica 
• Em SQL não há BEGIN TRANSACTION explícito 
• ROLLACK e COMMIT são explícitos 
• Características específicas: 
• Modo de acesso 
• Tamanho da área de diagnóstico 
• Nível de isolamento 
 
65 
Plano de Execução de Transações 
• Classificações 
• Modo de acesso 
• READ ONLY 
• READ WRITE 
• Tamanho da área de diagnostico 
• DIAGNOSTIC SIZE n 
• Nível de isolamento (ISOLATION LEVEL <I>) 
• READ UNCOMMITED (leitura suja) 
• READ COMMITED (leitura não-repetível) 
• REPEATABLE READ (fantasmas) 
• SERIALAZABLE 
 
66 
Plano de Execução de Transações 
• Dirty read (Leitura Suja) 
• EX: Suponha um BD de locadora de vídeos. Suponha 
que duas transações: 
• T1 venda de um vídeo e T2 inventário de 
estoque(ambas modificam a tabela vídeo) 
• Suponha a seguinte execução 
• 1. T1. Vende um dvd do filme ‘Titanic’ (havia 3 dvds 
então é modificado para 2) 
• 2. T2 verifica o estoque do DVD ‘Titanic’ e lê o valor 2 
DVDs 
• 3. T1 o cliente não tem crédito (“estorou o cartão“) e 
desiste da compra => Volta a existir 3 DVDs 
• 4. T2 imprime um relatório ERRADO com a 
informação de que existem 2 DVDs de ‘Titanic’ 
67 
Plano de Execução de Transações 
• Dirty read (Leitura Suja) 
68 
Plano de Execução de Transações 
• Non-repeatable read (Leitura não-repetível) 
• EX: Quando uma transação lê mais de uma vez um mesmo 
dado e obtém valores diferentes 
• Suponha duas transações: 
• T1 : lê duas vezes o número de DVDs do filme ‘Titanic’ (Ex. 
Cliente pergunta quantas cópias tem, espera um pouco e 
depois pede 2 cópias (que necessitará uma re-leitura) 
• T2: Compra todos os DVDs do filme ‘Titanic 
 
• 1. T1. Consulta o número de cópias de Titanic e obtém 3 
• 2. T2 Compra todas as cópias de Titanic => cópias = 0 
• 3. T1 Consulta o número de cópias de Titanic e obtém 0! 
 
Ou seja uma leitura diferente da anterior dentro da mesma transação 
69 
Plano de Execução de Transações 
• Non-repeatable read (Leitura não-repetível) 
70 
Plano de Execução de Transações 
• REPEATABLE READ (fantasmas) 
71 
Plano de Execução de Transações 
• Ex: Um administrador de banco de dados recebeu a solicitação 
de atualizar, no sistema de controle de estoque, o nome de um 
produto. De acordo com esse pedido, ele deveria alterar, 
diretamente no banco de dados, o valor do campo nome em uma 
única linha de uma tabela. No entanto, ele errou ao colocar o 
nome solicitado no update. Ao perceber o equívoco, aplicou o 
rollback nessa transação. Nesse período, um usuário reclamou 
que, ao realizar uma consulta no sistema, esse produto apareceu 
com o nome errado. Considerando-se que o erro percebido pelo 
usuário foi o mesmo introduzido pelo administrador, que 
fenômeno ocorreu nessa situação? 
 
(A) Dirty Read 
(B) Nonrepeatable Read 
(C) Phantom Read 
(D) Serializable Write 
(E) WriteNeverLock