Você está na página 1de 5

Transação

Uma transação é uma unidade de


Gerência de Transações „

computação consistente e confiável


Distribuídas ‰ Transparência de concorrência
‰ Transparência de falhas
Banco de Banco de dados pode estar em um Banco de
Fernanda Baião dados em um
estado
estado inconsistente durante a
execução
dados em um
estado
baiao@cos.ufrj.br consistente consistente

Outubro de 2003
Begin execução da End
Transaction transação Transaction

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 2

Transação – Exemplo Banco de Dados exemplo


Consulta SQL Simples
„ Considere uma base de reservas aéreas com as
Transaction BUDGET_UPDATE relações
begin
FLIGHT(FNO, DATE, SRC, DEST, STSOLD, CAP)
EXEC SQL UPDATE PROJ
CUST(CNAME, ADDR, BAL)
SET BUDGET = BUDGET * 1.1 FC(FNO, DATE, CNAME,SPECIAL)
WHERE PNAME = “CAD/CAM”
end.

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 3 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 4

Transação exemplo – Versão SQL Terminação de Transações


Begin_transaction Reservation
Begin_transaction Reservation begin
input(flight_no, date, customer_name);
begin EXEC SQL SELECT STSOLD,CAP
INTO temp1,temp2
input(flight_no, date, customer_name);
FROM FLIGHT
EXEC SQL UPDATE FLIGHT WHERE FNO = flight_no AND DATE = date;
if temp1 = temp2 then
SET STSOLD = STSOLD + 1 output(“no free seats”);
Abort
WHERE FNO = flight_no AND DATE = date;
else
EXEC SQL INSERT EXEC SQL UPDATEFLIGHT
SET STSOLD = STSOLD + 1
INTO FC(FNO, DATE, CNAME, SPECIAL); WHERE FNO = flight_no AND DATE = date;
EXEC SQL INSERT
VALUES (flight_no, date, customer_name, null); INTO FC(FNO, DATE, CNAME, SPECIAL);
output(“reservation completed”) VALUES (flight_no, date, customer_name, null);
Commit
end . {Reservation} output(“reservation completed”)
endif
end . {Reservation}

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 5 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 6

1
Transação exemplo – Leituras e Caracterização
Escritas
Begin_transaction Reservation
begin „ Conjunto leitura (RS)
input(flight_no, date, customer_name);
temp ← Read(flight_no(date).stsold); ‰ Conjunto de itens de dados lidos por uma
if temp = flight(date).cap then
begin
transação
output(“no free seats”);
Abort
„ Conjunto escrita (WS)
end ‰ Conjunto de itens de dados modificados por uma
else begin
Write(flight(date).stsold, temp + 1); transação
Write(flight(date).cname, customer_name);
Write(flight(date).special, null); „ Conjunto base (BS)
Commit;
output(“reservation completed”)
‰ RS ∪ WS
end
end. {Reservation}

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 7 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 8

Representação DAG Propriedades das Transações


„ ATOMICIDADE
‰ Tudo ou nada
‰ Em caso de falha, resultados parciais são desfeitos
„ Considere a transação ‰ Recuperação de transação x recuperação de falha
Read(x)
„ CONSISTÊNCIA
Read(y)
‰ Não viola restrições de integridade (programa correto)
x ←x + y ‰ Vários “graus”: T não sobrescreve dados ainda em atualização por
Write(x) outra transação (“sujos”),
Commit T não efetiva nenhuma escrita entes do EOT,
T não lê dados sujos,
dados lidos por T não são sujos antes do seu término
„ ISOLAMENTO
‰ Atualizações concorrentes são invisíveis
‰ Se várias transações são executadas concorrentemente, os
resultados devem ser os mesmos como se elas fossem executadas
serialmente em alguma ordem
„ DURABILIDADE
‰ Atualizações completadas com sucesso (commit) são persistentes
© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 9 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 10

Isolamento - Exemplo Tipos de Transações


„ Considere as 2 transações „ Baseados em
T1: Read(x) T2: Read(x) ‰ Áreas das aplicações
x ←x+1 x ←x+1 „ não distribuídas x distribuídas
Write(x) Write(x) „ transações compensatórias
Commit Commit „ transações heterogêneas
‰ Duração da transação
„ on-line (curta duração) x batch (longa duração)
„ Sequências de execução possíveis
‰ Organização das ações de leitura e atualização
T1: Read(x) T1: Read(x)
„ duas etapas (primeiro leituras, depois escritas)
T1: x ←x+1 T1: x ←x+1
„ restrita (toda atualização é precedida de uma leitura)
T1: Write(x) T2: Read(x)
Dados sujos e „ modelo de ação (restrita, cada par <leitura, escrita> é executado de
T1: Commit T1: Write(x) atualização forma atômica)
T2: Read(x) T2: x ←x+1 perdida!
‰ Estrutura
T2: x ←x+1 T2: Write(x)
„ transações planas
T2: Write(x) T1: Commit
„ transações aninhadas
T2: Commit T2: Commit
„ workflows

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 11 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 12

2
Workflow - Exemplo Modelo de Arquitetura

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 13 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 14

Execução de Transações Centralizadas Execução de Transações Distribuídas

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 15 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 16

Controle Distribuído da Concorrência Escalonamento (Schedule, ou History)


de Execução
„ O problema de sincronizar transações „ A ordem na qual as operações de um conjunto
concorrentes de forma a manter a de transações são executadas,
consistência do banco de dados e atingir, ao intercaladamente
mesmo tempo, nível elevado de concorrência
„ Anomalias: T1: Read(x) T2: Write(x) T3: Read(x)
Write(x) Write(y) Read(y)
‰ Atualizações perdidas
Commit Read(z) Read(z)
„ Os efeitos de algumas transações não são refletidos no
banco Commit Commit
‰ Leituras inconsistentes
„ Se uma transação lê um mesmo item de dado mais de
H1={W2(x),R1(x), R3(x),W1(x),C1,W2(y),R3(y),R2(z),C2,R3(z),C3}
uma vez, deve sempre encontrar o mesmo valor

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 17 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 18

3
Escalonamento de Execução Escalonamento Completo - Exemplo
Dadas 3 transações
T1 : Read(x) T2 :Write(x) T3 :Read(x)
„ 2 operações Oij(x) e Okl(x) estão em conflito se pelo Write(x) Write(y) Read(y)
menos 1 delas é operação de gravação Commit Read(z) Read(z)
Commit Commit
‰ leitura-gravação, gravação-gravação
‰ ordem de execução é importante Um possível escalonamento completo é dado como o DAG
„ Escalonamento completo
‰ estabelece a ordem de execução de todas as operações em seu
domínio

falhas resultam em escalonamentos incompletos... como lidar


com eles?
© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 19 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 20

Algoritmos de Controle de Algoritmos de Controle de


Concorrência Atrasam a
Concorrência
Sincronizam execução sincronização das
concorrente de transações até o seu „ Pessimistas
transações mais cedo Algoritmos de término
Controle da
Concorrência
Validate Read Compute Write
Pessimistas Otimistas

Bloqueio Ordenação Ordenação


Híbridos Bloqueio
(2PL) de timestamp de timestamp
„ Otimistas
Centralizado Básicos

Cópia Várias
Primária Versões Read Compute Validate Write

Distribuídos Conservativos

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 21 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 22

Algoritmos de Bloqueio Bloqueio em 2 fases (2PL)


„ Uma transação bloqueia um objeto antes de usá-lo
„ Quando um objeto está bloqueado por outra transação, a transação
„ Transações indicam suas intenções solicitando bloqueios solicitante do bloqueio deve aguardar
do escalonador (gerenciador de bloqueios). „ Quando uma transação libera um bloqueio, não pode solicitar outro
„ Bloqueios podem ser de leitura (rl) [bloqueio bloqueio
compartilhado] ou bloqueio de gravação (wl) [bloqueio
exclusivo]
„ Bloqueios de leitura e de gravação conflitam (porque
operações de leitura e escrita são incompatíveis
rl wl
rl yes no
wl no no
„ Bloqueios funcionam bem ao permitir processamento
concorrente de transações
© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 23 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 24

4
Ordenação por timestamp Algoritmos de CC Otimistas

„ É atribuído um timestamp único global ts(Ti ) para cada transação (Ti ) „ Modelo de execução da transação: dividir em subtransações, cada
„ Gerenciador de transações atribui o timestamp a todas as operações da uma executando em um nó
transação ‰ Tij : transação Ti que executa no nó j
„ A cada item de dado é atribuído um timestamp de gravação (wts) e um „ Transações executam independentemente em cada nó até que
timestamp de leitura (rts) alcançam o final da sua fase de leitura
‰ rts(x) = maior timestamp das transações que leram x „ Todas as subtransações recebem um timestamp no final da sua fase
‰ wts(x) = maior timestamp das transações que gravaram x de leitura
„ Operações conflitantes são resolvidas pela ordem do timestamp. „ Teste de Validação realizado durante a fase de validação. Se um
Algoritmo básico: falha, todas são rejeitadas
for Ri (x) for Wi (x)
if ts(Ti) < wts(x) if ts(Ti)<rts(x) and ts(Ti)<wts(x)
then reject Ri(x) then reject Wi(x) „ Nível mais alto de concorrência
else accept Ri(x) else accept Wi(x) „ Custo de armazenamento mais elevado
rts(x) <- ts(Ti) wts(x) <- ts(Ti)

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 25 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 26

Teste de Validação de CC Otimistas Impasses (Deadlocks)


„ Um impasse pode ocorrer porque as transações esperam uma pela
outra
„ Ordens possíveis „ Uma transação está em “deadlock” se está bloqueada e permanecerá
assim até que ocorra uma intervenção externa
„ Algoritmos de CC baseados em bloqueio podem resultar em
impasses
„ Algoritmos de ordenação de timestamp que exigem a espera de
transações também podem causar impasses
„ Gráfico de espera (Wait-for graph – WFG)
‰ Existe um arco Ti →Tj no WFG se a transação Ti estiver esperando que
outra transação Tj libere um bloqueio sobre alguma entidade.

© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 27 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 28

WFG locais x globais Gerência de Impasses


„ Ignorar…
‰ Deixe que o programador da aplicação lide com ele, ou re-inicie o sistema
„ Prevenção
‰ Garantir que os impasses nunca ocorram. Gerenciador de transações
verifica uma transação quando ela é iniciada e não permite que ela
prossiga se houver possibilidade de impasse. Não exigem suporte em
tempo de execução. Não adequada p/ SGBD
„ Anulação
‰ Detectam situações potenciais de impasse com antecedência e asseguram
que eles não ocorrerão (ordem pré-definida, timestamp). Exigem suporte
em tempo de execução.
„ Detecção e Recuperação (mais popular)
‰ Permitem que impasses ocorram, detectam-nos monitorando formação de
ciclos no WFG e rompendo-os. Exigem suporte em tempo de execução
© 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 29 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 30