04-transacoes

Prévia do material em texto

09/10/2013
1
Transações
Adaptado da aula do Professor Patrick Brito e Diego Dermeval 2
Situação problema
Transferência bancária
Conta C1 Conta C2
Saldo inicial = R$ 1000 Saldo inicial = R$ 2000
Transferência consiste em:
•C1 = C1 – 150 -> DÉBITO
•C2 = C2 + 150 -> CRÉDITO 
O que fazer quando o sistema falhar antes de 
completar a segunda operação (crédito) ?
3
Conceitos
Do ponto de vista do usuário: várias 
operações são vistas como uma só. Ex.: 
transferência bancária
DEFINIÇÃO: Operações que formam uma 
única unidade lógica de trabalho
4
Comandos
É delimitada por BEGIN TRANSACTION e END 
TRANSACTION
� Alternativas: 
� BEGIN WORK; END WORK;
� BEGIN; END;
� START TRANSACTION;
� END: commit. É uma extensão do PostgreSQL.
09/10/2013
2
5
Savepoints
É uma marca especial em uma transação 
que permite que todos os comandos 
executados após dela possam ser 
cancelados (abortados), recuperando a 
transação ao estado em que foi definido o 
savepoint
Comando:
� SAVEPOINT nome;
� ROLLBACK to nome;
� RELEASE SAVEPOINT nome;
6
Exemplos
BEGIN;
INSERT INTO table1 VALUES 
(1);
SAVEPOINT my_savepoint;
INSERT INTO table1 VALUES 
(2);
ROLLBACK TO SAVEPOINT 
my_savepoint;
INSERT INTO table1 VALUES 
(3);
COMMIT;
Insere os valores 1 e 3, mas não 2.
BEGIN;
INSERT INTO table1 VALUES 
(3);
SAVEPOINT my_savepoint;
INSERT INTO table1 VALUES 
(4);
RELEASE SAVEPOINT 
my_savepoint;
COMMIT;
Insere os valores 3 e 4
7
Propriedades
Para assegurar a integridade dos dados, 
exige-se que o BD tenha as seguinte 
propriedades:
� ATOMICIDADE: Executar todas as operações 
ou nenhuma
� CONSISTÊNCIA: Execução de transação 
isolada preserva a consistência do BD (soma 
de valores preservada) 
8
Propriedades (2) 
ISOLAMENTO: Execução de uma transação 
não é afetada pela execução de outras 
concorrentes (como se não existissem) –
componente de controle de concorrência
DURABILIDADE: Quando completada com 
sucesso, as mudanças persistem no BD mesmo 
se ocorrerem falhas – componente de 
gerenciamento de recuperação
Acrônimo ACID
09/10/2013
3
9
Exemplo
Enfatizando as operações 
de leitura e escrita
Read(x): transfere o item 
de dados X do BD para 
um buffer
Write(X): transfere X do 
buffer para o BD
Transfere $50 de A para 
B
Ti:
Read(A);
A:= A – 50;
Write(A);
Read(B);
B:= B + 50
Write(B);
10
Estado da Transação
Na ausência de falhas, todas se 
completam com sucesso. Se falhar, é 
abortada
Devido a atomicidade: 
� Não deve ter efeito algum sobre o estado do 
BD
� As alterações devem ser desfeitas
Quando as mudanças são desfeitas, 
dizemos rolled back - retornada
11
Estado da Transação (2) 
Gerenciar transações abortadas é 
responsabilidade do esquema de 
recuperação
Quando é completada com sucesso, 
dizemos efetivada (committed) 
Quando foi efetivada, não podemos 
desfazer seus efeitos abortando-a
12
Como recuperar-se?
O sistema mantém um log para 
acompanhar todas as operações das 
transações que afetam os valores dos itens 
dos bancos de dados
Log é mantido em disco
Será afetado apenas em falhas de disco ou 
catastróficas
09/10/2013
4
13
Grafo de estados
Ativa
Ativa
Em 
efetivação 
parcial
Em
efetivação
Abortada
Em
falha
Enquanto 
está
executando
Após execução
última instrução
Após 
conclusão
com sucesso
(dados já
no disco) 
Não será possível a execução normal
Desfeita
•A transação está concluída se estiver em efetivação ou abortada
•Em efetivação parcial: ainda na memória
•Supõe-se, por enquanto, que falhas não resultam em perdas no disco
14
Note que...
Quando diversas transações concorrentes são 
executadas, suas operações podem ser 
intercaladas de modo inconveniente resultando 
em estado inconsistente.
Exemplo: ler A e B e computar A+B após 
write(A) 
Solução: executar em série – mau desempenho. 
Por isso há opções que permitem que as 
transações concorram
15
Implementação de Atomicidade e 
Durabilidade
Feito pelo componente de gerenciamento
de recuperação
Considerando um esquema simples, mas 
ineficiente:
– Supõe que uma transação esteja ativa
por vez, baseia-se em cópias de BD(cópias shadow – sombra) 
– Ponteiro db_pointer aponta para a cópia
corrente do BD
16
Implementação de Atomicidade e 
Durabilidade (2) 
Transação cria uma cópia completa do BD
Atualizações são feitas na cópia shadow, 
deixando a original intacta
Se for abortada: apaga-se a cópia
Se for completada:
Cópia 
antiga 
do BD
Nova
cópia
db_pointer
09/10/2013
5
17
Implementação de Atomicidade e 
Durabilidade (2) 
Transação cria uma cópia completa do BD
Atualizações são feitas na cópia shadow, 
deixando a original intacta
Se for abortada: apaga-se a cópia
Se for completada:
Cópia 
antiga 
do BD
Nova
cópia
db_pointer
18
Implementação de Atomicidade e 
Durabilidade (3) 
E como fica a concorrência?
Exemplo: sessão de edição de texto (modelada 
como uma transação) 
Salvar o texto significa efetivar a transação
Sair sem salvar significa abortar a transação
Esta implementação é ineficiente, pois faz 
cópias do BD inteiro e não permite concorrência
19
Sistema monousuário versus 
Sistema Multiusuário
Exemplos:
� reservas em companhias aéreas
� bancos
� mercado acionário
� supermercados
Vários usuários acessam 
concomitantemente devido ao conceito de 
multiprogramação (“pseudo-paralelismo”)
20
Multiprogramação
Execução de alguns comandos de um 
processo A;
Suspende-se o processo A e executa-se 
alguns comandos do processo B;
Retoma-se o processo A do ponto em que
foi suspenso quando chegar a sua vez de 
utilizar a CPU;
Execução concorrente de processos é 
entrelaçada;
09/10/2013
6
21
Processamento entrelaçado 
versus paralelo
Tempo
A
BB
A
D
C CPU1
CPU2
T1 T2 T3 T4
T1-T2: processamento entrelaçado
T3-T4: processamento paralelo (mais de uma CPU) 22
Execuções Concorrentes
Traz complicações de consistência (exige mais 
trabalho) 
Razões para permitir a concorrência:
� Aproveitamento de recursos (I/O e CPU): maior 
número de transações executadas num certo tempo
� Transações curtas e longas: curtas podem esperar 
muito. Reduz tempo médio de resposta
Enfim, mesma motivação da multiprogramação 
de S.O.
23
Execuções Concorrentes (2) 
Algumas ordens de execução garantem a 
manutenção da consistência (schedules ou 
escalas de execução): controle de concorrência
Schedules – seqüência que indica a ordem em 
que as instruções de transações concorrentes 
serão executadas
� Uma escala para um conjunto de transações deve 
consistir de todas as instruções daquelas transações
� Deve preservar a ordem na qual as instruções 
aparecem em cada transação individual
24
Exemplo de escala
T1 transfere $50 de A para B, e T2 transfere 10% do saldo de A para
B. Abaixo uma escala em série, em que T1 é seguida de T2
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) 
Suponha A = $ 1000
e B = $ 2000
09/10/2013
7
25
Escalas
PERGUNTA: Se a ordem de execução for 
alterada (T2 e depois T1), a consistência do BD 
é mantida???
Em escalas seqüenciais de n transações há n! 
escalas válidas diferentes
Se as transações forem executadas 
simultaneamente, o número de escalas 
possíveis é muito maior que n!
26
Exercício: 
As duas escalas são consistentes?
T1 T2
read(A)
A := A – 50
write(A)
read (A)
temp := A*0.1
A = A – temp
write(A) 
read(B)
B := B + 50
write(B)
read(B)
B := B + temp
write(B) 
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) 
B := B + temp
write(B) 
27
Ou seja...
Se o S.O. controlar a execução 
concorrente, escalas que levam à 
inconsistência poderão ocorrer.
28
Serialização
Considerar read e write
Serialização de conflito
� Seja uma escala S com duas instruções Ii e Ij das 
transações Ti e Tj. Se as instruções referem-se a 
itens de dados diferentes, pode-se alternar Ii e Ij sem 
problemas
� Se referem-se ao mesmo item de dados Q, a ordem 
importa!
09/10/2013
8
29
Casos
Quando as duas instruções são read não 
há problema
� Quando uma delas é write
� E são de transações diferentes
� E acessam o mesmo item de dados
ELAS ESTÃO EM CONFLITO!!!
30
Exemplo
T1 T2
read(A)
write(A)
read (A)
write(A)
read (B)
write(B)
read (B)
write(B) 
Write(A) de T1
está em conflito com
read(A) de T2
31
Se não há conflito...
Podemos trocar a ordem, produzindo uma nova 
escala de execução equivalente
32
Resultado
Uma escala seqüencial
Isto mostra que a escala anterior é equivalente à 
seqüencial
DEFINIÇÃO: se uma escala S puder ser 
transformada em outra S’, por uma série de 
trocas de instruções não conflitantes, dizemos 
que S e S’ são equivalentes no conflito
09/10/2013
9
33
Serialização de conflito
Uma escala de execução S é conflito 
serializável se ela é equivalente no conflito 
a uma escala de execução seqüencial.
34
Exemplo – não conflito serializável
T3 T4
R(Q)
W(Q) 
W(Q) 
T3 T4
R(Q) 
W(Q) 
W(Q) 
T3 T4
W(Q) 
R(Q) 
W(Q) 
35
Verificação
A escala abaixo e a 
seqüencial 
<T1, T5> produzem o 
mesmo resultado?
Teste com 
A = 1000 e 
B = 2000
T1 T5
read(A)
A := A – 50
write(A)
read(B)
B := B – 10
write(B)
read(B)
B := B + 50
write(B)
read(A)
A := A + 10
write(A) 
36
Conclusão
Assim, vê-se que há definições menos
restritivas de equivalência de escala que a 
equivalência de conflito.
– É possível garantir consistência, mesmo
quando duas transações não são
equivalentes no conflito;
– Não é conflito-serializável, mas 
apresenta resultado equivalente. Como 
isso é possível?
09/10/2013
10
T1 T2
R(X)
X:=X-N
W(X)
R(Y)
Y:=Y+N
W(Y)
R(X)
X:=X+M
W(X)
T1 T2
R(X)
X:=X-N
W(X)
R(X)
X:=X+M
W(X)
R(Y)
Y:=Y+N
W(Y)
Dada a escala ao lado, responda:
a) Há instruções em conflito? Quais?
b) É conflito serializável? Se for, qual 
a escala seqüencial?
=