aula_final

Prévia do material em texto

TransaçõesTransações
 
Introdução a TransaçõesIntrodução a Transações
• SGBD  sistema de processamento de operações de 
acesso ao BD.
• SGBDs são em geral multi-usuáriosmulti-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.
• Operações são chamadas transaçõestransações
 
TransaçãoTransação
• Uma transação é uma unidade de 
execução de programa que acessa e, 
possivelmente atualiza vários itens de 
dados. 
 
TransaçãoTransação
 De forma abstrata e simplificada, uma transação pode 
ser encarada como um conjunto de operações de 
leitura(read) e escrita(write) de dados.
 Read(x) – transfere o item X do banco de dados para 
um buffer local alocado a transação que executou a 
operação de read.
 Write(x) – transfere o item de dados X do buffer local 
da transação que executou a write de volta ao banco 
de dados.
Tx
 
ExemploExemplo
• Seja Ti uma transação que transfere 50 
dólares da conta A para conta B. Essa 
transação pode ser definida como:
TI: read(A);
A:=A-50;
write(A);
read(B);
B:=B+50;
write(B)
passo a passo
Leitura da Conta A: 1.000
A:=1000-50;
A=950;
Leitura da Conta B: 2.000
B:=2.000+50;
B=2.050
 
Propriedades de uma TransaçãoPropriedades de uma Transação
• Para assegurar integridade dos dados, exigimos 
que o sistema de banco de dados mantenham as 
seguintes propriedades das transações: ACID
• AA tômicidade: para o mundo externo, a transação 
ocorre de forma indivisível.
• CC onsistência: a transação não viola invariantes de 
sistema.
• II solamento: transações concorrentes não interferem 
entre si (serializable).
• DD urabilidade: os efeitos de uma transação terminada 
com commit são permanentes.
Commit - encerra a transação (solicita efetivação 
das suas ações)
 
AtomicidadeAtomicidade
• Princípio do “Tudo ou Nada”“Tudo ou Nada”
– ou todas as operações da transação são 
efetivadas com sucesso no BD ou nenhuma 
delas se efetiva
• preservar a integridade do BD
• Responsabilidade do subsistema de 
recuperação contra falhas do SGBD
– desfazer as ações de transações parcialmente 
executadas
 
Situação ProblemaSituação Problema
• Suponhamos que, antes da execução da transação Ti 
os valores das contas A e B sejam 1.000 e 2.000 reais, 
respectivamente. Agora suponha que, durante a 
execução da transação Ti uma falha (falta de energia, falha 
na máquina e erros de software) aconteceu impedindo Ti de 
se completar com sucesso. Suponha que a falha 
ocorrida tenha sido depois da operação write(A), mas 
antes da operação write(B). Nesse caso os valores das 
contas A e B refletidas no banco são A: 950 e B: 2000 
reais. Como resultado da falha sumiram 50 reais.
• Chamamos esse estado de inconsistente. Devemos 
assegurar que essas inconsistências sejam 
imperceptíveis em um banco de dados
• Se a propriedade de atomicidade for garantida, todas 
as ações da transação serão refletidas no banco de 
dados ou nenhuma delas o será.
 
AAtomicidadetomicidade
• Deve ser garantida, pois uma transação 
pode manter o BD em um estado 
inconsistente durante a sua execução.
read(A)
A.saldo = A.saldo – 50,00
write(A)
read(B)
B.saldo = B.saldo + 50,00
write(B)
Ti (transferência bancária)
número saldo
100 1.000
200 2.000
. . .
Contas
A
B falha!
execução
•A idéia básica por trás da garantia da ATOMICIDADE é a seguinte: 
O SGBD matem um registro (em disco) dos antigos valores de 
quaisquer dados sobre os quais a transação executa uma gravação e, 
se a transação não completar, os valores antigos são restabelecidos 
para fazer com que pareça que nunca foi executada. Assegurar a 
atomicidade é função do próprio sistema de BD.
 
CConsistênciaonsistência
• Uma transação sempre conduz o BD de um 
estado consistente para outro estado 
também consistente
 
IIsolamentosolamento
• No contexto de um conjunto de transações concorrentes, 
a execução de uma transação Ti deve funcionar como se 
Ti executasse de forma isolada
– Ti não deve sofrer interferências de outras transações 
executando concorrentemente
• A propriedade de isolamento de uma transação garante 
que a execução simultânea de transação resulte em uma 
situação no sistema equivalente ao estado obtido caso 
as transações tivessem sido executadas uma de cada 
vez em qualquer ordem.
 
IIsolamentosolamento
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 - A
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 - A
write(B)
escalonamento válido escalonamento inválido
T1 
interfere 
em T2
T2 
interfere 
em T1
 
DDurabilidade ou Persistênciaurabilidade ou Persistência
• 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
 
Estados de uma TransaçãoEstados 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?
 Estados de uma transação
 Ativa; Em processo de efetivação; Efetivada; 
Em processo de aborto; Concluída.
 
 
Transição de Estados de uma Transição de Estados de uma 
TransaçãoTransaçã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
 
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
Transição de Estados de uma Transição de Estados de uma 
TransaçãoTransação
 
encerramento
sem sucessoAtiva
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
(solicitação de COMMIT) 
• neste momento, o SGBD 
precisa garantir que as suas 
atualizações sejam efetivadas 
com sucesso (não sofra falhas)
Transição de Estados de uma Transição de Estados de uma 
TransaçãoTransaçã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 OK)
– exemplos: gravação em Log, 
descarga de todos os buffers
em disco 
encerramento
sem sucesso
Transição de Estados de uma Transição de Estados de uma 
TransaçãoTransação
 
Transição de Estados de uma Transição de Estados de uma 
TransaçãoTransaçã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 Informações
– exemplo (II): pane no S.O. suas ações já realizadas devem ser desfeitas
 (ROLLBACK)
encerramento
sem sucesso
 
encerramento
sem sucessoAtiva
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
Transição de Estados de uma Transição de Estados de uma 
TransaçãoTransação
 
Comandos
 COMMIT: indica o término de uma transação 
bem-sucedida.
 ROLLBACK: assinala o término de uma 
transação malsucedida.
 
Comandos
 set autocommit=0;
 start;
− Comandos;
− Comandos....
 Commit;
 Rollback;
 set autocommit=1;
 
Exemplo: 
 mysql> use test;
mysql> create table tabela_teste (a int, b int) 
engine = InnoDB;
 mysql> begin;
mysql> insert into tabela_teste (a,b) values 
(1,2);
 mysql> select * from tran_test; 
 mysql> rollback;
 mysql> select * from tran_test;
 
Exercício
Crie uma transação para:
Buscar o salário de uma tabela onde o id for 1. 
Após, atualizar em outra tabela este valor. 
 
• Responsável pela definição de escalonamentos não-seriais de 
transações
• “Um escalonamento E define uma ordem de execução das 
operações de várias transações, sendo que a ordem das 
operações de uma transação T1 em E aparece na mesma ordem 
na qual elas ocorrem isoladamente em T1”
• Problemas de um escalonamento não-serial mal definido (inválido)
– atualização perdida (lost-update)
– leitura suja (dirty-read)
SchedulerScheduler
 
• Uma transação T1 grava em um dado 
atualizado por uma transação T2
T1 T2
read(A)
A = A – 50
read(C)
A = D + 10
write(A)
read(B)
write(A)
E = A + 30
write(B)
a atualização de A 
por T1 foi perdida!
Atualização PerdidaAtualização Perdida ((lost-lost-
updateupdate))
 
• T1 atualiza um dado A, outras transações 
posteriormente lêem A, e depois T1 falha
T1 T2
read(A)
A = A – 20
write(A)
read(A)
A = A + 10
write(A)
read(Y)
abort( )
T2 leu um 
valor de A 
que 
não será mais 
válido!
LeituraLeitura SujaSuja (dirty-readdirty-read)
Neste ponto, a 
transação T1 
falha e deve 
retornar o valor 
de A para o seu 
valor antigo;
 
Exemplo java
 Connection con; // Conexão com o B.D 
 conn.setAutoCommit(false); 
 try { 
 // Bloco de Código 
 con.commit(); // Se estiver tudo ok, grava as alterações no B.D. 
 catch (Exception e) { 
 con.rollback(); // Descarta todas alterações, feitas desde o inicio da 
transação 
 System.out.println("Falha ao gravar dados: " + e.toString()); 
 } 
 conn.setAutoCommit(true); 
 
Crie uma transação em java para buscar um 
valor em uma tabela e salvar este valor em 
outra tabela.
vendas(id int auto_increment, valor double, item 
int);
Balanco(id int auto_increment, soma double, 
item int);
 
Controle de Concorrência - Controle de Concorrência - 
TransaçõesTransações
• SGBDSGBD
– sistema multiusuário em geral
• diversas transações executando simultaneamente
• Garantia de isolamentoisolamento de Transações
– 1a solução: uma transação executa por vez
• EscalonamentoEscalonamento serialserial de transações
• solução bastante ineficiente!
– várias transações podem esperar muito tempo para serem 
executadas
– CPU pode ficar muito tempo ociosa
» enquanto uma transação faz I/O, por exemplo, outras 
transações poderiam ser executadas
• solução mais eficiente
– execução concorrente de transações de modo a preservar 
o isolamento
» escalonamento (schedule) não-serial e íntegro
 
• As técnicas de controle de concorrência 
garantem que várias transações 
submetidas por vários usuários não 
interfiram umas nas outras de forma a 
produzir resultados inconsistentes.
• Um scheduleschedule (escala) representa uma 
seqüência de operações realizadas por 
transações concorrentes.
Controle de Concorrência - Controle de Concorrência - 
TransaçõesTransações
 
T1 T2
read(A)
A = A – 50
write(A)
read(B)
B = B + 50
write(B)
read(A)
temp:=A*0,1
A:=A – temp
write (A)
read(B)
B:=B+temp
write(B)
Controle de Concorrência - Controle de Concorrência - 
TransaçõesTransações
• Os dois schedules(escalas) apresentados são seriais, ou seja, as transações são 
executadas de forma seqüencial, uma seguida da outra.
• Entretanto a execução de schedules seriais limita o acesso concorrente aos 
dados e, por conseqüência, diminui o throughput (quantidade de trabalho 
realizado em um intervalo de tempo). T1 T2
read(A)
A = A – 50
write(A)
read(B)
B = B + 50
write(B)
read(A)
temp:=A*0,1
A:=A – temp
write (A)
read(B)
B:=B+temp
write(B)
 
• Nem todas as 
execuções 
concorrentes 
resultam em um 
estado correto.
• Esse estado final é 
um estado 
inconsistenteinconsistente, 
pois a soma de A + 
B não é preservada 
na execução das 
duas transações
T1 T2
read(A)
A = A – 50
read(A)
temp:=A*0,1;
A := A –temp
write(A)
read(B)
write(A)
read(B)
B = B + 50
write(B)
Escala Concorrente ou execução Escala Concorrente ou execução 
não-serialnão-serial
Controle de Concorrência - Controle de Concorrência - 
TransaçõesTransações
 
• Responsável pela definição de 
escalonamentos não-seriais de transações
• “Um escalonamento E define uma ordem de 
execução das operações de várias 
transações, sendo que a ordem das 
operações de uma transação T1 em E 
aparece na mesma ordem na qual elas 
ocorrem isoladamente em T1”
• Problemas de um escalonamento não-serial 
mal definido (inválido)
– atualização perdida (lost-update)
– leitura suja (dirty-read)
SchedulerScheduler
 
• Uma transação T1 grava em um dado 
atualizado por uma transação T2
T1 T2
read(A)
A = A – 50
read(C)
A = D + 10
write(A)
read(B)
write(A)
E = A + 30
write(B)
a atualização de A 
por T1 foi perdida!
Atualização PerdidaAtualização Perdida ((lost-lost-
updateupdate))
 
• T1 atualiza um dado A, outras transações 
posteriormente lêem A, e depois T1 falha
T1 T2
read(A)
A = A – 20
write(A)
read(A)
A = A + 10
write(A)
read(Y)
abort( )
T2 leu um 
valor de A 
que 
não será mais 
válido!
LeituraLeitura SujaSuja (dirty-readdirty-read)
Neste ponto, a 
transação T1 
falha e deve 
retornar o valor 
de A para o seu 
valor antigo;
 
41
Exercício Deadlock.
Considere o seguinte conjunto de transações e suas respectivas instruções. Estas transações
 entram em deadlock? Justifique. T1 T2
Lock-X(A)
Read(A)
Lock-S(B)
Lock-X(B)
Read(X)
Write(X)
Lock-X(A)
Usuário X e S.
Transação T1 e T2.
Registro A e B.
42
Exercício Deadlock.
Considere o seguinte conjunto de transações e suas respectivas instruções. Estas transações
 entram em deadlock? Justifique. T1 T2
Lock-X(A)
Read(A)
Lock-S(B)
Lock-X(B)
Read(X)
Write(X)
Lock-X(A)
Sim, pois T1 solicita bloqueio exclusivo sobre o item B (que já está bloqueado em modo conflitante por T2) e precisa esperar; 
e T2 solicita bloqueio exclusivo sobre o item A (que já está bloqueado em modo conflitante por T1) e precisa esperar.
Usuário X e S.
Transação T1 e T2.
Registro A e B.
43
44
GRAUS DE ISOLAMENTO
SERIALIZABLE:
PERMITE APENAS ESCALAS SERIALIZAVEIS SEREM EXECUTADAS.
BLOQUEIA OS DADOS ATÉ O FINAL DA TRANSAÇÃO E IMPEDE A 
INSERÇÃO DE NOVAS TUPLAS NAS TABELAS EM USO.
MODO MAIS RESTRITO, QUE RESULTA EM MENOR CONCORRÊNCIA.
REPEATABLE READ:
BLOQUEIA OS DADOS ATÉ O FINAL DA TRANSAÇÃO.
GARANTE QUE OS VALORES DOS DADOS ACESSADOS NÃO SEJAM 
MODIFICADOS POR OUTRAS TRANSAÇÕES, MAS PERMITE INSERIR TUPLAS.
READ COMMITED:
OS VALORES DOS DADOS ACESSADOS NÃO PODEM SER MODIFICADOS POR
OUTRAS TRANSAÇÕES. OPCAO DEFAULT.
READ UNCOMMITED (outro usuário vai ler sem levar em conta a transação):
NÃO USABLOQUEIO. É O MODO MENOS RESTRITO. 
TEM MAIOR CONCORRÊNCIA E DEVE SER USADO QUANDO NÃO SE TEM 
NENHUM COMPROMISSO COM A CONSISTÊNCIA DO RESULTADO. 
 
•Deve evitar escalonamentos 
inválidos
– exige análise de operações em 
conflito
•operações que pertencem a transações 
diferentes
•transações acessam o mesmo dado
•pelo menos uma das operações é write
SchedulerScheduler
 
Scheduler X RecoveryScheduler X Recovery
• Scheduler deve cooperar com o Recovery!
• Categorias de escalonamentos 
considerando o grau de cooperação com o 
Recovery
– recuperáveis X não-recuperáveis
– permitem aborto em cascata X evitam aborto 
em cascata
– estritos X não-estritos
 
Transações em SQLTransações em SQL
• Uma linguagem de Manipulação de dados deve 
possui um construtor para especificar o conjunto de 
ações que constitui uma transação. 
• Por default, todo comando individual é considerado 
uma transação
– exemplo: DELETE FROM Pacientes
• exclui todas ou não exclui nenhuma tupla de pacientes, deve 
manter o BD consistente, etc
• SQL Padrão (SQL-92)
– SET TRANSACTION
• inicia e configura características de uma transação
– COMMIT [WORK]
• encerra a transação (solicita efetivação das suas ações)
– ROLLBACK [WORK]
• solicita que as ações da transação sejam desfeitas
 
• Principais configurações (SET TRANSACTION)
– modo de acesso
• READ (somente leitura), WRITE (somente atualização) ou READ 
WRITE (ambos - default)
– nível de isolamento
• indicado pela cláusula ISOLATION LEVEL nível
• nível para uma transação Ti pode assumir
– SERIALIZABLE (Ti executa com completo isolamento - 
default)
– REPEATABLE READ (Ti só lê dados efetivados e outras 
transações não podem escrever em dados lidos por Ti) – 
pode ocorrer que Ti só consiga ler alguns dados que deseja
– READ COMMITTED (Ti só lê dados efetivados, mas outras 
transações podem escrever em dados lidos por Ti)
– READ UNCOMMITTED (Ti pode ler dados que ainda não 
sofreram efetivação)
Transações em SQLTransações em SQL
 
• Garante que, se TA realizou commit (encerra a transação (solicita 
efetivação das suas ações)), TA não irá sofrer UNDO (desfazer uma 
atualização no BD)
– o recovery espera sempre esse tipo de escalonamento!
• Um escalonamento E é recuperável se nenhuma TA em E for 
concluída até que todas as transações que gravaram dados lidos por 
TA tenham sido concluídas
T1 T2
read(A)
A = A – 20
write(A)
read(A)
A = A + 10
write(A)
commit( )
abort( )
escalonamen
to
não-
recuperável
T1 T2
read(A)
A = A – 20
write(A)
read(A)
A = A + 10
write(A)
commit( )
commit( )
escalonamento
recuperável
Escalonamento RecuperávelEscalonamento Recuperável
 
• Um escalonamento recuperável pode gerar abortos de 
transações em cascata
– consome muito tempo de recovery!
• Um escalonamento E é recuperável e evita aborto em 
cascata se uma TA em E só puder ler dados que tenham 
sido atualizados por transações que já concluíram
T1 T2
read(A)
A = A – 20
write(A)
read(A)
A = A + 10
write(A)
abort( ) . . .
escalonamento
recuperável
com aborto em
cascata
T1 T2
read(X)
A = A – 20
write(A)
commit( )
read(A)
A = A + 10
write(A)
. . .
escalonamento
recuperável
sem aborto em
cascata
Escalonamento sem Aborto em Escalonamento sem Aborto em 
CascataCascata
 
• Garante que, se TA deve sofrer UNDO, basta gravar a before image 
dos dados atualizados por ela
• Um escalonamento E é recuperável, evita aborto em cascata e é 
estrito se uma TA em E só puder ler ou atualizar um dado A depois 
que todas as transações que atualizaram A tenham sido concluídas
T1 T2
read(A)
A = A – 20
write(A)
read(B)
A = B + 10
write(A)
commit( )
abort( )
escalonamento
recuperável
sem aborto em
cascata e
não-estrito
T1 T2
read(A)
A = A – 20
write(A)
commit( )
read(B)
A = B + 10
write(A)
commit( )
escalonamento
recuperável
sem aborto em
cascata e
estrito
Escalonamento EstritoEscalonamento Estrito
	Diapositivo 1
	Diapositivo 2
	Diapositivo 3
	Diapositivo 4
	Diapositivo 5
	Diapositivo 6
	Diapositivo 7
	Diapositivo 8
	Diapositivo 9
	Diapositivo 10
	Diapositivo 11
	Diapositivo 12
	Diapositivo 13
	Diapositivo 14
	Diapositivo 15
	Diapositivo 16
	Diapositivo 17
	Diapositivo 18
	Diapositivo 19
	Diapositivo 20
	Diapositivo 22
	Diapositivo 23
	Diapositivo 24
	Diapositivo 25
	Diapositivo 27
	Diapositivo 28
	Diapositivo 29
	Diapositivo 30
	Diapositivo 31
	Diapositivo 32
	Diapositivo 33
	Diapositivo 34
	Diapositivo 35
	Diapositivo 36
	Diapositivo 37
	Diapositivo 38
	Diapositivo 40
	Diapositivo 41
	Diapositivo 42
	Diapositivo 43
	Diapositivo 44
	Diapositivo 45
	Diapositivo 46
	Diapositivo 47
	Diapositivo 48
	Diapositivo 49
	Diapositivo 50
	Diapositivo 51