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

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 2 2 2 2

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 3 3 3 3

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 4 4 4 4

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 5 5 5 5

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

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

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

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 9 9 9 9

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 10 10 10 10

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 11 11 11 11

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 12 12 12 12

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 13 13 13 13

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 14 14 14 14

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. 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 15 15 15 15

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

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

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 18 18 18 18

Protocolo Write de Thomas Uma variação do Protocolo de ordenação por Timestamp Considere o Schedule abaixo: T1 T2 read(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 19 19 19 19

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 20 20 20 20

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

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 22 22 22 22

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 23 23 23 23

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 24 24 24 24

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

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 26 26 26 26

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 27 27 27 27

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 28 28 28 28

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 29 29 29 29

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 30 30 30 30

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 31 31 31 31

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 32 32 32 32

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 33 33 33 33

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 34 34 34 34

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 35 35 35 35

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 36 36 36 36

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 37 37 37 37

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 38 38 38 38

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

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 40 40 40 40

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 Copiar no quadro 41 41 41 41 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 Copiar no quadro 42 42 42 42 42

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 43 43 43 43

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 44 44 44 44

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 45 45 45 45

Protocolo Granularidade Múltipla Matriz de compatibilidade de Bloqueios de intenção IS IX S SIX X true false 46 46 46 46 46

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 47 47 47 47

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

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 49 49 49 49

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 50 50 50 50

Protocolos baseados em Múltipla versão Considerações Os esquemas de controle de concorrência vistos anteriormente asseguram a seriação adiando operações ou abortando a transação que gerou a operação. Ex: uma leitura adiada, aguardando uma escrita. Como isso poderia ser sanado ? 51 51 51 51 51

Protocolos baseados em Múltipla versão Mantendo cópias de dados Q, com timestamp Assegurando a seriação De forma rápida Timestamp (TS) associado Históricos de Q 52 52 52 52 52

Protocolos baseados em Múltipla versão Estrutura Conteúdo W-timestamp R-timestamp Conteúdo – o valor da versão Qk. W-timestamp (Qk) – é o timestamp da transação que criou a versão Qk R-timestamp (Qk) – é o MAIOR timestamp de qualquer transação que leu com sucesso a versão Qk 53 53 53 53 53

Protocolos baseados em Múltipla versão Regras Inicialização - Um novo Qk é criado quando um Ti faz um write (Q). W-Timestamp e R-timestamp recebem o TS(Ti). O valor de R-timestamp é atualizado sempre que uma transação Tj lê o conteúdo de Qk e R-timestamp(Qk) < TS(Tj) T1 T2 read(A); A = A*1.50; write(A); 54 54 54 54 54

Protocolos baseados em Múltipla versão Regras Ti é uma transação emitindo Read(Q) ou Write (Q). Qk indica a versão de Q cujo W-timestamp seja o maior W-timestamp <= TS (Ti). 1) Se a transação Ti emitir um read (Q), então o valor retornado é o conteúdo da versão Qk 2) Se a transação Ti emitir write (Q) e se TS(Ti) < R-timestamp(Qk), então o sistema reverte a transação Ti. Por outro lado de TS(Ti) = W-timestamp(Qk), o sistema escreve sobre o conteúdo de Qk. Caso contrário, ele cria uma nova versão de Q Exemplo anexo 55 55 55 55 55

Protocolos baseados em Múltipla versão Remoção de versões antigas Para otimizar uso de memória: Se tivermos duas versões Qj e Qk e o W-timestamp < TS(Transação mais antiga), a mais antiga entre Qj e Qk pode ser excluída por não ser mais usada 56 56 56 56 56

Protocolos baseados em Múltipla versão Vantagens 1) A leitura nunca falha e nunca espera (o que é mais feito em um BD ? Leitura ou escrita) Desvantagens 1) Ao ler, atualiza-se R-timestamp, gerando mais acesso a disco 2) Conflitos não geram espera, mas rollback 57 57 57 57 57

Protocolos baseados em Múltipla versão Características Assegura a seriação ? Previne deadlock ? Previne rollback em cascata ? Starving pode acontecer Sim Não Não Sim 58 58 58 58 58

O problema do impasse (deadlock) na concorrência Ocorre quando uma transação Ti bloqueia um recurso R1 e Tj necessita deste recurso. Ocorre que Tj bloqueia um recurso R2. E Ti irá precisar do recurso R2 também. Ou seja Tj é bloqueada por Ti que aguarda Tj, em uma espera perpétua. Pode ocorrer entre mais de duas transações também. EXEMPLO ANEXO 59 59 59 59 59

O problema do impasse (deadlock) na concorrência Considerações Só existe devido à permissão de concorrência no SGBD Pode ser tratado preventivamente, evitando que ocorra (preferível) Pode ser tratado reativamente, garantindo a execução normal e consistência do BD 60 60 60 60 60

O problema do impasse (deadlock) na concorrência Prevenção de impasse Geralmente usado em sistemas com alta probabilidade de ocorrer deadlocks Custo de implantação que precisa ser justificado Existem duas técnicas, vistas a seguir 61 61 61 61 61

O problema do impasse (deadlock) na concorrência Prevenção de impasse – técnicas 1) Nenhuma espera cíclica poderá ocorrer, através da ordenação das solicitações de bloqueios OU exige que todos os bloqueios sejam adquiridos juntos 2) Sempre que a espera puder potencialmente gerar um deadlock, executa rollback 62 62 62 62 62

O problema do impasse (deadlock) na concorrência Prevenção de impasse – bloqueio total 1) Difícil prever quais dados devem ser bloqueados ANTES do início da transação 2) A efetiva utilização de dados pode ser baixa, podendo gerar espera elevada 63 63 63 63 63

O problema do impasse (deadlock) na concorrência Prevenção de impasse – ordenação dos bloqueios A transação deve bloquear seguindo a ordenação dos itens de dados (semelhante ao protocolo de árvore) 64 64 64 64 64

O problema do impasse (deadlock) na concorrência Prevenção de impasse – preempção e rollback Preempção (apropriação) – Se T2 solicitar um bloqueio que T1 mantém, o bloqueio de T1 pode apropriado pela reversão de T1 e concessão deste bloqueio a T2 (sob determinadas condições) A técnica de prevenção por preempção e rollback tem dois esquemas. 65 65 65 65 65

O problema do impasse (deadlock) na concorrência Prevenção de impasse – preempção e rollback Atribuem Timestamp a cada transação, caso precise decidir se vai esperar ou reverter. Se reverter a transação, esta mantém o Timestamp antigo. 66 66 66 66 66

O problema do impasse (deadlock) na concorrência Prevenção de impasse – wound-wait Esquema ferir-esperar (preemptiva) Se uma transação Ti tenta acessar um dado bloqueado por Tj, temos Se TS(Ti) > TS(Tj), Ti espera Se não, Tj é revertido (Tj é ferido por Ti) 67 67 67 67 67

O problema do impasse (deadlock) na concorrência Prevenção de impasse – wait-die (não preemptiva) Esquema esperar-morrer Se uma transação Ti tenta acessar um dado bloqueado por Tj, temos Se TS(Ti) < TS(Tj), Ti espera Se não, Ti é revertido (morre) 68 68 68 68 68

O problema do impasse (deadlock) na concorrência Prevenção de impasse Os dois esquemas previnem starving(estagnação) Por que ? Toda transação nova recebe um timestamp maior que o das transações anteriores. Quando há reversão, o timestamp continua o mesmo. Em algum momento, este timestamp será menor e não será mais revertido. 69 69 69 69 69

O problema do impasse (deadlock) na concorrência Prevenção de impasse O esquema ferir-esperar pode gerar menos rollbacks que o esperar-morrer. O esperar-morrer pode gerar uma reversão após a outra. Uma transação com TS menor tende a gerar mais reversões. No ferir-esperar, uma transação mais antiga nunca espera uma nova 70 70 70 70 70

O problema do impasse (deadlock) na concorrência Esquemas baseados em tempo limite Uma transação Ti solicita um bloqueio sobre o dado Q. Se este dado Q estiver bloqueado, ela aguarda um tempo determinado. Se após o tempo, o bloqueio ainda permanecer, há a reversão de Ti 71 71 71 71 71

O problema do impasse (deadlock) na concorrência Esquemas baseados em tempo limite Fácil implantação Funciona bem com transações curtas Quanto deve ser o tempo limite ? Tempo longo → atrasos desnecessários em caso de impasse Tempo curto → excesso de rollbacks mesmo sem impasse 72 72 72 72 72

O problema do impasse (deadlock) na concorrência Detecção e recuperação de impasse Deve-se usar um protocolo que impeça o deadlock OU Gerenciá-lo quando ocorrer. No último caso, um algortimo está sempre checando o status do sistema, para detectar deadlocks 73 73 73 73 73

O problema do impasse (deadlock) na concorrência Requisitos do sistema para detecção/recuperação Manter informações sobre a alocação atual dos itens de dados e solicitações de itens pendentes Algoritmo que use esta informação para determinar se o sistema está em impasse Recuperar-se de impasse de forma adequada e garantindo a consistência 74 74 74 74 74

O problema do impasse (deadlock) na concorrência Detecção de impasse Um gráfico direcionado, chamado gráfico de espera (wait-for) é uma boa maneira de saber se existe um impasse no sistema Os vértices são as transações e as arestas, as dependências de bloqueio. Se Ti aponta para Tj, indica que Ti depende de Tj. Caso haja um ciclo, há impasse. Exemplo a seguir 75 75 75 75 75

O problema do impasse (deadlock) na concorrência Detecção de impasse – gráfico de espera Como é a leitura deste gráfico ? Um algoritmo fica percorrendo de tempos em tempos a estrutura do gráfico (mantida pelo SGBD), à procura de impasse 76 76 76 76 76

O problema do impasse (deadlock) na concorrência Recuperação de impasse A partir da detecção do impasse, pelo controle de concorrência, o SGBD deve agir: 1) Selecionar a(s) vítima(s), considerando-se um custo mínimo: a) Por quanto tempo a transação executou e quanto ainda falta para sua conclusão b) Quantos itens de dados a transação usou c) Quantos itens de dados a mais a transação ainda necessita para terminar d) Quantas transações estarão envolvidas no rollback 77 77 77 77 77

O problema do impasse (deadlock) na concorrência Recuperação de impasse 2) Rollback – sabendo qual transação reverter, podemos ter dois tipos de rollback: Total – desfaz toda a transação Parcial – desfaz a transação até o ponto em que não há mais impasse 78 78 78 78 78

O problema do impasse (deadlock) na concorrência Recuperação de impasse T1 lock(A) read(A) A=100; write(A) lock(B) read(B) B = A + 50; write(B) Se houver impasse no item B, até onde deverá ser feito um rollback parcial ? 79 79 79 79 79

O problema do impasse (deadlock) na concorrência Recuperação e Estagnação(Starving) Se as vítimas dos rolbacks forem sempre as mesmas, poderá gerar estagnação. Uma forma de evitar é incluir o número de rollbacks sofridos no fator de custo. 80 80 80 80 80

Operações de inclusão/exclusão Problemas Se Ti tentar read(Q), após um delete(Q), resulta em erro lógico Se Ti tentar read(Q), antes de um insert(Q), resulta em erro lógico 81 81 81 81 81

Operações de inclusão/exclusão Exclusão (deleção) e os conflitos Para Ii (da transação Ti) = Delete(Q), considere as instruções Ij (da transação Tj). Assuma que Ti vem antes de Tj 1 - Ij = read (Q) - select 2 - Ij = write(Q) - update 3 - Ij = delete(Q) a) Se Ij vier antes de Ii, Tj terá erro lógico. b) Se vier depois, ok a) Se Ij vier antes de Ii, Tj ok b) Se vier depois, Tj terá erro lógico a) Se Ij vier antes de Ii, Tj terá erro lógico b) Se vier depois, Tj terá erro lógico 82 82 82 82 82

Operações de inclusão/exclusão Exclusão (deleção) e os conflitos Para Ii (da transação Ti) = Delete(Q), considere as instruções Ij (da transação Tj). Assuma que Ti vem antes de Tj 4 - Ij = insert (Q) Se o dados Q NÃO EXISTISSE: Se o dados Q EXISTISSE: a) Se Ij vier antes de Ii, Tj ok. b) Se vier depois, terá erro lógico. a) Se Ij vier antes de Ii, Tj erro lógico. b) Se vier depois, ok. 83 83 83 83 83

Operações de inclusão/exclusão Conclusão Sob o protocolo de bloqueio em duas fases, um bloqueio exclusivo é exigido sobre um item de dados antes que esse item possa ser excluído Sob o protocolo ordenação por timestamp: Se TS(Ti) < R-timestamp(Q), então o valor (Q) a ser excluído já foi lido por Tj, com TS(Tj)>TS(Ti). Logo delete é rejeitado e Ti é revertida Se TS(Ti) < W-Timestamp(Q), então uma transação Tj com TS(Tj) > TS (Ti) escreveu Q. Logo o delete é rejeitado e Ti é revertida. 84 84 84 84 84

Operações de inclusão/exclusão Inclusão e os conflitos Como insert realiza um write, sempre há conflito com read ou write posterior. Nenhum read ou write pode ser realizado antes que ele exista. Sob o protocolo de bloqueio em duas fases, receberá um bloqueio exclusivo sobre o item Q recém-criado. Sob o protocolo ordenação por timestamp, ao realizar um Insert(Q), os valores R-timestamp(Q) e W-Timestamp são definidos como TS(Ti) 85 85 85 85 85

O fenômeno fantasma Considere as transações: T29 T30 Select sum(saldo) From contas Where Agencia = 1001 Insert into contas (conta,agencia,saldo) Values (1,1001,900); Se T29 usar a tupla de T30, em um schedule serial, T30 deve vir antes de T29 Se T29 NÃO usar a tupla de T30, em um schedule serial, T29 deve vir antes de T30 86 86 86 86 86

O fenômeno fantasma O conflito existe sem haver nenhuma tupla em comum ! Conta Agencia Saldo Bloq. T29 1 1001 100 Sim 2 500 3 550.17 4 17 100.00 Não Bloqueio de índice, para evitar este problema 87 87 87 87 87

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