bases de dados 2013/2014 transações - técnico lisboa · • a soma a+b tem de ser igual antes e...

11/20/13

1

Bases de Dados 2013/2014 Transações

Helena Galhardas

Sumário!•  Conceito de Transação!

– Propriedades ACID!•  Conflitos e Serializabilidade!•  Recuperabilidade!•  Protocolos de controlo de concorrência!•  Transações em SQL!•  Recuperação de falhas!

© 2013 Técnico Lisboa

11/20/13

2

Referências

•  Raghu Ramakrishnan, Database Management Systems, 3ª edição: Cap 16


Transacção (1) Conjunto de operações de um programa que formam uma unidade lógica de trabalho na qual podem ser acedidos e atualizados vários dados, por exemplo:

–  Transferir dinheiro da conta bancária A para a B: 1. !read(A)!!! !2.!A := A – 50!!! !3.!write(A)!!! !4.!read(B)!!! !5.!B := B + 50!!! !6.!write(B)!

–  Reservar uma viagem, etc Transacção é a visão abstracta que o SGBD tem de um

programa de utilizador: sequência de leituras e escritas © 2013 Técnico Lisboa

11/20/13

3

Transacção (2) •  Lista de acções ou instruções

–  leituras ou escritas sobre objectos da BD –  commit se a transacção termina com sucesso

(por omissão, supõe-se que a transacção termina com sucesso na última instrução)

–  abort ou rollback se a transacção não termina e todas as suas ações têm que ser anuladas

•  Assume-se que : – Transacções interagem umas com as outras só

através de operações de leituras e escritas da BD – Uma BD é uma colecção fixa de objectos

independentes


Visão Simplificada das Transacções

•  Só consideramos as instruções de leitura e escrita na análise


3

11/20/13

4

Motivação para a concorrência •  Execução concorrente de programas é

essencial para um bom desempenho da BD – Enquanto uma transacção espera que uma página

seja lida do disco, o CPU pode processar outra transacção

–  Intercalar as actividades de E/S e de CPU reduz o tempo que os discos e processador estão inactivos

•  aumenta o desempenho do sistema de BD (em nº transações/unid. tempo)

•  reduz o tempo médio de resposta das transações: as curtas não precisam de esperar pelas longas.


Transacções e Concorrência A forma mais fácil de garantir que 2 transações não interferem seria executá-las em série...mas: •  pequenas transações

teriam de esperar pela conclusão de transações mais demoradas

•  Transações que não entram em conflito seriam obrigadas a esperar desnecessariamente

T1 T2read (A)A := A – 50write (A)read (B)B := B + 50write (B)commit

read (A)temp := A * 0.1A := A tempwrite (A)read (B)B := B + tempwrite (B)commit


11/20/13

5

Concorrência num SGBD

•  Concorrência é conseguida pelo SGBD intercalando acções (leituras e escritas de objectos da BD) de várias transacções

•  Cada transacção tem de deixar a BD num estado consistente se ela estiver consistente quando a transacção se iniciar – o SGBD não compreende a semântica da

transacção


Propriedades ACID

•  Atomicidade •  se a transação falhar entre os

passos 4–6, os passos 1–3 ficam sem efeito

•  Coerência •  a soma A+B tem de ser igual antes e depois

•  Isolamento •  nenhuma outra operação deve ler os valores de A e B entre os

passos 3 e 6 (verá um valor inconsistente)

•  Durabilidade •  se a transação termina com sucesso, as alterações são

definitivas, mesmo que o hw ou sw falhem © 2012 Técnico Lisboa

Ti : read(A) A := A – 50 write(A) read(B) B := B + 50 write(B)

1 2 3 4 5 6


11/20/13

6

[A] Atomicidade •  Numa transacção, as alterações ao estado são

atómicas: ou todas se realizam ou nenhuma se realiza •  Falha de transacções porque:

–  SGBD termina-a devido a anomalia durante a execução –  Crash de sistema (ex: falha de corrente) –  Transacção encontra situação inesperada (ex: não consegue

aceder a disco) e aborta

•  Função do Sistema: manter informação sobre as alterações efectuadas por cada transacção activa (num ficheiro de log) e, em caso de aborto, desfazer as alterações das transacções incompletas


[C] Coerência (Integridade) •  Uma transação é uma transformação correta de estado

–  Supõe-se que o conjunto das ações da transação não viola nenhuma das regras de integridade associadas ao estado.

–  Isto requer que a transação seja um programa correto

•  Função do Sistema: coerência assegurada por regras de integridade; não é esperado que o SGBD detecte incoerências nos dados devido a erros na programação


11/20/13

7

[I] Isolamento

•  Embora as transações se executem concorrentemente, qualquer transação T’ cuja execução se sobreponha com a de uma transação T, aparece, do ponto de vista de T, como tendo sido executada na totalidade antes de T ou depois de T (execução em série)

•  Função do Sistema: garantir que uma transação apenas “vê” alterações realizadas por outras transações terminadas com sucesso

[D] Durabilidade (Persistência) •  Uma vez completada com sucesso uma transação

(commit concluído), todas as alterações ao estado são imutáveis, sobrevivendo a qualquer tipo de falta do sistema

•  Função do Sistema: manter informação sobre alterações efectuadas por cada uma das transações commited (num ficheiro de log) e, em caso de falha refazer as alterações que ainda não se encontravam registadas em disco

11/20/13

8

Exemplo •  Considere as duas transacções:

T1: BEGIN A=A+100,B=B-100 END!T2: BEGIN A=1.06*A, B=1.06*B END!

•  Intuitivamente, a primeira transfere 100 da conta B para a A e a segunda credita em ambas contas com 6% de juros

•  Não existe garantia que T1 se execute antes de T2 ou vice-versa, mas o resultado tem que ser equivalente às duas transacções se executarem em série por uma determinada ordem

Exemplo (cont.) •  Considere um possível escalonamento das operações

(schedule)


•  Tudo bem! E este?

T1: ! A=A+100, ! ! B=B-100 !T2: ! ! A=1.06*A, ! ! B=1.06*B!

T1: ! A=A+100, ! ! ! !B=B-100 !T2: ! ! A=1.06*A, B=1.06*B!

•  A visão do SGBD sobre o segundo escalonamento:

T1: ! R(A), W(A), ! ! ! R(B), W(B)!T2: ! ! !R(A), W(A), R(B), W(B)!

11/20/13

9

Escalonamento (schedule) •  Lista de acções (leitura, escrita, abort, ou commit) de um

conjunto de transacções em que a ordem em que duas acções de uma transacção T aparecem no escalonamento é a mesma em que aparecem na transacção –  Representa uma sequência de execução potencial ou real –  Descreve as acções das transacções tal como vistas pelo SGBD

•  Um escalonamento que contém uma instrução de abort ou commit de cada transacção diz-se completo

Anomalias com execução concorrente

•  Leitura de dados uncommitted (Conflitos WR, dirty reads)

T1: !R(A), W(A), ! R(B), W(B), Abort!T2: ! ! !R(A), W(A), C!

•  Unrepeatable reads (Conflitos RW, dirty reads)

T1: !R(A), ! ! ! R(A), W(A), C!T2: ! !R(A), W(A), C!

11/20/13

10

Anomalias com execução concorrente(cont)

•  Overwriting uncommitted data (Conflitos WW)

T1: !W(A), ! ! W(B), C!T2: ! !W(A), W(B), C!

Tipos de escalonamentos •  Escalonamento em série: escalonamento em que não

existem acções de diferentes transacções intercaladas

•  Escalonamentos equivalentes: se, para qualquer estado da BD, o efeito (no conjunto dos objectos da BD) de executar o primeiro escalonamento é igual ao de executar o segundo

•  Escalonamento serializável: escalonamento que é equivalente a alguma execução em série das transacções

11/20/13

11

Escalonamentos em Série


2 1



T1 T2

read (A)A := A – 50write (A)read (B)B := B + 50write (B)commit



Escalonamentos Equivalentes O Escalonamento 3 não é em série, mas é equivalente a um em série (logo, serializável)

–  em ambos, a soma A+B é preservada

1 3



T1 T2read (A)A := A – 50write (A)

read (B)B := B + 50write (B)commit

read (A)temp := A * 0.1A := A tempwrite (A)

read (B)B := B + tempwrite (B)commit

11/20/13

12

O escalonamento 4 não preserva A+B © 2012 Técnico Lisboa

Escalonamento não serializável

4 3

T1 T2read (A)A := A – 50

write (A)read (B)B := B + 50write (B)commit

read (A)temp := A * 0.1A := A tempwrite (A)read (B)

B := B + tempwrite (B)commit

T1 T2read (A)A := A – 50write (A)

read (B)B := B + 50write (B)commit

read (A)temp := A * 0.1A := A tempwrite (A)

read (B)B := B + tempwrite (B)commit

Sumário!•  Conceito de Transacção!

– Propriedades ACID!Ø Conflitos e Serializabilidade!•  Recuperabilidade!•  Protocolos de controlo de concorrência!•  Transações em SQL!•  Recuperação de falhas!

11/20/13

13


Conflitos na Ordem das Instruções

Num escalonamento onde duas transacções T1 e T2 acedem ao mesmo objecto Q •  T1: read(Q) e T2: read(Q)

–  a ordem é indiferente •  T1: read(Q) e T2: write(Q)

–  Há conflito: a ordem é relevante •  T1: write(Q) e T2: read(Q)

–  Há conflito: a ordem é relevante •  T1: write(Q) e T2: write(Q)

–  Há conflito: a ordem não afecta nem T1 nem T2 mas afecta a próxima instrução de read(Q)


Teste de Serializabilidade Forma simples de determinar se um escalonamento é serializável •  construir um grafo de precedências

–  os nós são transações (T1, T2, ..., Tn) –  os arcos são conflitos (Ti → Tk )

•  desenha-se um arco de Ti para Tk se –  Ti : write(Q) antes de Tk : read(Q) –  Ti : read(Q) antes de Tk : write(Q) –  Ti : write(Q) antes de Tk : write(Q)

•  Ciclos implicam não serializabilidade

T1 T2

11/20/13

14


Teste de Serializabilidade: Exemplos 1 e 3

2 1

Teste de Serializabilidade: Exemplo 4

O escalonamento 4 de <T1, T2> não é serializável

© 2012 Técnico Lisboa 4

11/20/13

15

Teste de serializabilidade

•  Um escalonamento é serializável se o seu grafo de precedências não tiver ciclos (se for acíclico)

•  Se o grafo for acíclico, as transações podem ser executadas por qualquer ordem que respeite o grafo



– Propriedades ACID!•  Conflitos e Serializabilidade!Ø Recuperabilidade!•  Protocolos de controlo de concorrência!•  Transações em SQL!•  Recuperação de falhas!


11/20/13

16


Commit

Uma transacção que se completa com sucesso tem uma instrução de commit como última instrução

commit commit


Recuperação em escalonamentos

Uma transacção que falha tem uma instrução de abort ou rollback como última instrução (undo)

commit rollback

11/20/13

17


Escalonamento Não Recuperável

•  Problema: quando T8 falha, T9 já completou e não pode ser cancelada –  este escalonamento não é recuperável

commit rollback


Escalonamentos Recuperáveis

Considerar apenas escalonamentos recuperáveis –  estes escalonamentos devem obedecer à seguinte

condição:

Para qualquer par de transacções Ti e Tk se Ti executa write(Q) antes de Tk executar read(Q) então Ti faz commit antes de Tk fazer commit

commit commit

11/20/13

18

•  Erro numa transacção pode levar ao rollback de várias transacções

•  Comportamento indesejado –  pode obrigar a desfazer várias tarefas já realizadas

Rollbacks em cadeia


erro!

rollback


Considerar apenas escalonamentos sem hipótese de rollback em cadeia estes escalonamentos devem obedecer à seguinte

condição:

Esta condição garante que o escalonamento é também recuperável

Para qualquer par de transacções Ti e Tk se Ti executa write(Q) antes de Tk executar read(Q) então Ti faz commit antes de Tk fazer read

Rollback em cadeia

11/20/13

19


Protocolo de controlo de concorrência

•  Os escalonamentos devem ser serializáveis, recuperáveis e preferencialmente sem rollbacks encadeados –  um sistema em que só corre 1 transação de cada

vez garante isto, mas elimina a concorrência •  Logo, são necessários protocolos que

maximizem a concorrência, mas garantam as condições de serializabilidade desejadas

•  Exemplo: Strict Two Phase Locking só permite escalonamentos serializáveis e recuperáveis

Strict Two Phase Locking

1.  Se uma transacção T quer ler (ou modificar) um objecto, primeiro pede um lock partilhado (ou exclusivo) sobre o objecto

2.  Todos os locks atribuídos a uma transacção são libertados quando a transacção se completa


11/20/13

20


– Propriedades ACID!•  Conflitos e Serializabilidade!•  Recuperabilidade!•  Protocolos de controlo de concorrência!Ø Transações em SQL!Ø Recuperação de falhas!


Definição de Transações em SQL

•  A linguagem SQL tem elementos para dizer que as consultas fazem parte de uma transação

•  Em SQL, qualquer consulta, actualização ou criação de tabela inicia implicitamente uma transacção que só termina com – commit – torna os resultados permanentes – rollback – cancela todas as alterações (undo)


11/20/13

21


Sintaxe

•  Executar uma transacção start transaction;!!!…!!!commit; !ou !rollback;!

•  Vários sistemas usam autocommit por omissão

–  se start transaction for omitido •  cada consulta é uma transacção •  se houver erros, rollback automático •  se não houver erros, commit automático


Exemplo Verificar saldos:

select balance from account where account_number = 'A-101';!!select balance from account where account_number = 'A-102';!

Transferir 350€ da conta A-101 para a conta A-102:

start transaction;!!update account set balance = balance – 350 where

!account_number = 'A-101';!!update account set balance = balance + 350 where

!account_number = 'A-102';!!commit;!

11/20/13

22

Duas novas primitivas SQL:1999

•  Savepoint – permite identificar um ponto de uma transacção e selectivamente efectuar o rollback das acções executadas depois deste ponto –  Útil para transacções longas –  savepoint <nome>!–  rollback to savepoint <nome>

•  Chained transactions – permite que se faça commit ou rollback de uma transacção e se inicie imediatamente outra transacção –  Útil para executar transacções umas atrás das outras –  Commit/rollback and chain!


Sumário!•  Conceito de Transacção!

– Propriedades ACID!•  Conflitos e Serializabilidade!•  Recuperabilidade!•  Protocolos de controlo de concorrência!•  Transações em SQL!Ø Recuperação a falhas!


11/20/13

23

Recuperação de falhas

•  Para anular as acções de uma transacção que abortou (atomicidade), o SGBD mantém um ficheiro de log (diário) em que cada escrita é registada

•  Mecanismo também usado para recuperar de falhas de sistema – Todas as transacções activas na altura da

falha são abortadas quando o sistema é reposto


Log


•  São guardadas as seguintes acções no log: –  Se Ti escreve um objecto: valor antigo e valor novo

–  Registo de log tem que ser guardado em disco antes da página mudada o ser

–  Se Ti faz commit ou abort: é escrito registo de log indicando esta acção

•  Registos de log são guardados por transacção para ser fácil anular uma transacção específica

•  Log é muitas vezes duplicado ou guardado em memória estável

•  Todas as actividades de logging são tratadas de forma transparente pelo SGBD

11/20/13

24

Algoritmo de recuperação de falhas


•  Três fases do algoritmo Aries: 1.  Análise: Percorrer o log para a frente (a partir do

checkpoint mais recente) para identificar todas as transacções que estavam activas e todas as páginas sujas existentes no buffer na altura da falha

2.  Redo: Refazer todas as modificações correspondentes a páginas no buffer, se necessário, para assegurar que todas as modificações registadas no log são, de facto, escritas em disco

3.  Undo: percorrer o ficheiro de log para trás e anular todas as escritas efectuadas por transacções que estavam activas no momento da falha (repondo o valor antigo conforme registo de modificação no log)

Sumário

•  Transacções •  Próxima aula: Gestão de controlo de

concorrência – Garante coerência dos dados e isolamento se

estiver garantida a atomicidade das transacções

47

bases de dados 2013/2014 transações - técnico lisboa · • a soma a+b tem de ser igual antes e...

Documents