UNDB

1. UNDB BANCO DE DADOS II Prof. Alessandro Gonçalves Alessandro.inovacao@gmail.com 1

2. Bloqueio em duas fases Considerações É eficiente Implantado independente da ordem como os itens são acessados, pois todos os bloqueios de duas fases garantem a seriação 2

3. Bloqueios baseados em gráfico Considerações Deve ser feita ordenação parcial, para garantir a seriação de conflito: Se Di vem antes de Dj, qualquer transação deverá ler Di antes de Dj Assim, o gráfico será acíclico (gráfico de banco de dados) Existem vários bloqueios baseados em gráfico. Estudaremos o mais simples. 3

4. Protocolo de árvore Considerações Baseado em gráfico 1. Trabalha somente com bloqueios exclusivos 2. Pode bloquear um item de dados no máximo uma vez 3. Primeiro bloqueio por Ti pode ser sobre qualquer item 4

5. Protocolo de árvore Considerações 4. Um item de dados Q pode ser bloqueado por Ti somente se o pai de Q estiver atualmente bloqueado por Ti. 5. Os itens de dados podem ser desbloqueados a qualquer momento 6. Um item de dados que foi bloqueado e desbloqueado por Ti não pode mais tarde ser bloqueado novamente por Ti 5

6. Protocolo de árvore Considerações Todos os schedules legais são seriais de conflito 6

7. Protocolo de árvore A Cada Nó = lock-E(Dado) B C F D E G H I ... J 7

8. Bloqueio de árvore Características Asseguram a seriação ? Previnem deadlock ? Previnem rollback em cascata ? Sim Sim Não 8

9. Bloqueio de árvore Como assegurar que não haverá rollback em cascata ? 1. Manter os bloqueios até o final da transação OU 2. Sempre que uma transação Ti realiza leitura sobre um item de dados gravado por Tj, é marcada dependência de commit . Ti só terá a leitura confirmada após o Commit de Tj 9

10. Bloqueio de árvore x 2 fases O bloqueio de árvore pode liberar o bloqueio mais cedo Pode acontecer do bloqueio de árvore ter de bloquear itens de dados que não acessa (ex: A,J->B,D,H) É mandatório conhecer a ordem de acesso dos dados, no bloqueio de árvore 10

11. Protocolo timestamp Timestamp se refere à marcação em que determinada transação entrou na fila de execução É exclusivo (não se repete) Indicado por TS(Ti). Sempre que Ti vier antes de Tj, TS(Ti) < TS(Tj) 11

12. Protocolo ordenação por timestamp Duas formas de determinar o valor do timestamp Contador único – cada transação recebe um número e incrementa este número Clock – utiliza o clock do sistema para atribuir este valor à transação Os timestamps determinam a ordem da seriação. Se TS(Ti) < TS(Tj), Ti deve aparecer ANTES em qualquer schedule válido sob este protocolo 12

13. Protocolo ordenação por timestamp Dois tipos de timestamp R-timestamp(Q) – último (maior) timestamp de leitura W-timestamp(Q) – último (maior) timestamp de escrita Ver exemplo Anexo 13

14. Protocolo ordenação por timestamp Conflito read x write A transação Ti -> read(Q) 1) Se TS(Ti) < W-timestamp(Q), rejeita e reverte Ti. Por que ? 2) Se TS(Ti) >= W-timestamp(Q), então a operação read é executada. R-timestamp é atualizado. Ti quer ler um valor já atualizado por outro 14

15. Protocolo ordenação por timestamp Conflito read x write A transação Ti -> write(Q) 1) Se TS(Ti) < R-timestamp(Q), rejeita e reverte Ti. Por que ? 2) Se TS(Ti) < W-timestamp(Q), rejeita e reverte Ti. Por que ? 3) Caso contrário, executa a operação e atualiza W-timestamp O valor que Ti produz foi necessário anteriormente mas nunca seria produzido Ti quer atualizar um valor já atualizado por outro 15

16. Protocolo ordenação por timestamp Reversão Transação recebe um novo timestamp e reinicia Exemplo anexo 16

17. Protocolo ordenação por timestamp Resumindo Assegura a seriação ? Previne deadlock ? Previne rollback em cascata ? Starving pode acontecer Sim Sim Sim* Sim 17

18. Protocolo ordenação por timestamp Prevenção de rollback em cascata e facilidade de recuperação Escritas precisam ser atômicas e feitas ao final. Nenhuma transação pode ler antes do commit; As leituras de itens não confirmados são adiadas até a confirmação (bloqueio limitado). A facilidade de recuperação pode ser garantida, permitindo que uma transação Ti seja confirmada após o Commit de uma transação que escreveu um valor que Ti leu (protocolo baseado em gráfico) 18

19. Protocolo Write de Thomas Uma variação do Protocolo de ordenação por Timestamp Considere o Schedule abaixo: T1 T2 read(A) write(A) write(A) O que acontece sob o Protocolo de ordenação por timestamp ? Como TS(T1) < TS(T2) e sendo o write de T1 < w-timestamp, seria revertido. 19

20. Protocolo Write de Thomas Uma variação do Protocolo de ordenação por Timestamp A transação Ti -> write(Q) 1) Se TS(Ti) < R-timestamp(Q), rejeita e reverte Ti. 2) Se TS(Ti) < W-timestamp(Q), ignora Ti, por ser obsoleto 3) Caso contrário, executa a operação e atualiza W-timestamp 20

21. Protocolo Write de Thomas Resumindo Gera schedules com seriação de visão É uma especialização do protocolo ordenação por timestamp 21

22. Protocolos baseados em validação Considerando A concorrência gera benefícios. Gera problemas também ? Em caso de schedules com muitas leituras (reads) ? Como ficam os conflitos ? Como saber quais transações estarão em conflitos ? 22

23. Protocolos baseados em validação Um sistema de monitoramento, com 3 fases seriadas: 1) Fase de leitura – Ele lê todos os itens de Ti e executa o write em variáveis locais à transação (sem gravação no BD). 2) Fase de validação – A transação testa se pode copiar as variáveis locais temporárias do write, sem causar violação da seriação 3) Fase de escrita – Se a fase 2 for bem sucedida, aplicam-se as atualizações no banco de dados. Senão, reverte Ti. 23

24. Protocolos baseados em validação Um sistema de monitoramento, com 3 fases seriadas: 1) Start (Ti) 2) Validation (Ti) 3) Finish (Ti) Utiliza-se a ordenação de Timestamp. O timestamp da transação será o timestamp da fase Validation. 24

25. Protocolos baseados em validação Exemplo anexo 25

26. Protocolos baseados em validação Para a transação Tj, todas as transações Ti com TS(Ti) < TS(Tj), UMA DAS condições precisa ser verdadeira 1) Finish(Ti) < Start (Tj). 2) O conjunto de dados ESCRITOS por Ti não são lidos por Tj e Ti completa sua fase de escrita antes que Tj inicie sua validação. Start (Tj) < Finish (Ti) < Validation (Tj) Como Ti termina antes de Tj começar, a seriação é mantida. Como as escritas de Ti não afetam a leitura de Tj e como Tj não pode afetar a leitura de Ti, a ordem de seriação é mantida 26

27. Protocolos baseados em validação Características Assegura a seriação ? Previne deadlock ? Previne rollback em cascata ? Starving pode acontecer Sim Sim Sim Sim 27

28. Protocolos baseados em validação Características Esquema de controle de concorrência otimista São capazes de concluir a execução e validar no final Pessimista – força espera ou rollback ao conflitar Ex: timestamp 28

29. Resultados da Provinha 1 Comente sobre as propriedades ACID do banco de dados ATOMICIDADE – Uma transação é executada na sua totalidade ou nada é feito (tudo ou nada) 29

30. Resultados da Provinha 1 Comente sobre as propriedades ACID do banco de dados CONSISTÊNCIA – A transação ao ser executada, leva o banco de um estado consistente a outro estado consistente. 30

31. Resultados da Provinha 1 Comente sobre as propriedades ACID do banco de dados ISOLAMENTO – Uma transação sendo executada não toma conhecimento de outras sendo executadas (age como se fosse a única) 31

32. Resultados da Provinha 1 Comente sobre as propriedades ACID do banco de dados DURABILIDADE – Ao final da confirmação dos dados, estes persistem, mesmo com falhas no sistema. 32

33. Resultados da Provinha 1 Exemplo: A transação Ti está alterando um dado X A transação Tj está excluindo o dado X ISOLAMENTO 33

34. Resultados da Provinha 1 Exemplo: A transação Ti gravou um dado, que foi confirmado. Logo após o SGBD apresentou problemas. Mas o dado gravado por TI continuava o mesmo. DURABILIDADE 34

35. Resultados da Provinha 1 Exemplo: Em uma transação Ti, havia: begin read(A) A:=A+50; write(A) commit; Se houver erro no commit, nada é feito ATOMICIDADE 35

36. Resultados da Provinha 1 Exemplo: Em uma transação Ti, havia: begin read(A) A:=A+50; write(A) commit; A tinha um valor 100. Agora tem 150. CONSISTENCIA 36

37. Resumo Concorrência: 1) Por que ? 2) Problemas 3) Como implantar ? 4) Seriação: transforma um schedule serial em equivalente 5) Pode ser conflito ou visão 37

38. Resumo Concorrência: 6) A partir dos seriais acima, existem protocolos 7) Matriz de compatibilidade de bloqueios 8) Protocolo em 2 fases 9) Protocolo Árvore 10) Protocolo Timestamp 38

39. Resumo Concorrência: 10) Write de Thomas 11) Protocolo baseado em validação 39

40. Protocolo Granularidade Múltipla Considere: Os bloqueios foram vistos como bloqueios em itens de dados individuais. Mas em caso de necessidade de bloquear o BD inteiro ou boa parte dele ? Granularidade Dados agrupados e com tamanhos diferentes, em uma árvore hierárquica (mas <> do Protocolo em Árvore) 40

41. Protocolo Granularidade Múltipla Banco de dados BD Área de dados A1 A2 A2 Lock A2 Fa Fb Fc Fc Arquivo (tabela) (bloqueio explícito x implícito) Ra1 Ra2 Ra3 Rb3 Rc1 Rc1 RcN RcN ... Registro 41 Copiar no quadro

42. Protocolo Granularidade Múltipla Banco de dados BD Área de dados A1 A2 A2 Lock A2 Fa Fb Fc Fc Arquivo (tabela) (bloqueio explícito x implícito) Ra1 Ra2 Ra3 Rb3 Rc1 Rc1 RcN RcN ... Registro 42 Copiar no quadro

43. Protocolo Granularidade Múltipla No exemplo anterior, com os nós bloqueados. Se uma Transação Tj tentar Bloquear (exclusivo ou compartilhado) Rc1, por exemplo, o que deve ser feito ? Como saber se posso bloquear ? 43

44. Protocolo Granularidade Múltipla Modo de bloqueio de intenção Extensão da matriz de compatibilidade de bloqueio Os ancestrais dos nós recebem um bloqueio de intenção O nó a ser bloqueado, recebe o bloqueio de fato Bloqueios percorrem da raiz até o nó Desbloqueios, inversamente, do nó até a raiz. 44

45. Protocolo Granularidade Múltipla Bloqueios de intenção Ancestrais IS – Intention Shared – Compartilhado de intenção IX – Intention Exclusive – Exclusivo de intenção SIX – Shared e Intention Exclusive – Compartilhado e exclusivo de intenção Nós X – Exclusive – Exclusivo S – Shared – Compartilhado 45

46. Protocolo Granularidade Múltipla Matriz de compatibilidade de Bloqueios de intenção 46

47. Protocolo Granularidade Múltipla Regras do Protocolo Cada Transação Ti pode bloquear um nó Q desde que: 1) O bloqueio solicitado segue a matriz de compatibilidade de intenção 2) Precisa bloquear a raiz da árvore e em qualquer modo 3) Pode bloquear um nó Q no modo S ou IS somente se atualmente tiver bloqueado o pai de Q no modo IX ou IS 4) Pode bloquear um nó Q no modo X, IX ou SIX somente se atualmente tiver o pai de Q bloqueado no modo IX ou SIX 47

48. Protocolo Granularidade Múltipla Como ficam os bloqueios no Schedule abaixo ? T1 T2 T3 T4 Read (Ra1) Write (Ra2) Read(Fa) Read (DB)

49. Protocolos baseados em Granularidade múltipla Resumo Útil principalmente Transações curtas que acessam apenas alguns itens de dados Transações longas que produzem relatórios de um arquivo inteiro ou conjunto de arquivos 49

50. Protocolos baseados em Granularidade múltipla Características Assegura a seriação ? Previne deadlock ? Previne rollback em cascata ? Starving pode acontecer Sim Não Não Sim 50