UNDB

UNDB

BANCO DE DADOS II

Prof. Alessandro Gonç[email protected]

1

Bloqueio em duas fases

2

Considerações

É eficiente

Implantado independente da ordem como os itens são acessados, pois todos os bloqueios de duas fases garantem a seriação

Bloqueios baseados em gráfico

3

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.

Protocolo de árvore

4

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


5

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


6

Considerações

Todos os schedules legais são seriais de conflito


7

A

B C

F

E

I

D

G H

J

Cada Nó = lock-E(Dado)

...

Bloqueio de árvore

8

Características

Asseguram a seriação ?

Previnem deadlock ?

Previnem rollback em cascata ?

Sim

Não

Sim

Bloqueio de árvore

9

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

Bloqueio de árvore x 2 fases

10

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

Protocolo timestamp

11

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)

Protocolo ordenação por timestamp

12

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


13

Dois tipos de timestamp

R-timestamp(Q) – último (maior) timestamp de leitura

W-timestamp(Q) – último (maior) timestamp de escrita

Ver exemplo Anexo


14

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


15

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


16

Reversão

Transação recebe um novo timestamp e reinicia

Exemplo anexo


17

Resumindo

Assegura a seriação ?

Previne deadlock ?

Previne rollback em cascata ?

Starving pode acontecer

Sim

Sim*

Sim

Sim


18

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)

Protocolo Write de Thomas

19

Uma variação do Protocolo de ordenação por Timestamp

Considere o Schedule abaixo:

T1 T2read(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.


20

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


21

Resumindo

Gera schedules com seriação de visão

É uma especialização do protocolo ordenação por timestamp

Protocolos baseados em validação

22

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 ?


23

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.


24

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.


25

Exemplo anexo


26

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


27

Características


Previne deadlock ?



Sim

Sim

Sim

Sim


28

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

Resultados da Provinha 1

29

Comente sobre as propriedades ACID do banco de dados

ATOMICIDADE – Uma transação é executada na sua totalidade ou nada é feito (tudo ou nada)


30


CONSISTÊNCIA – A transação ao ser executada, leva o banco de um estado consistente a outro estado consistente.


31


ISOLAMENTO – Uma transação sendo executada não toma conhecimento de outras sendo executadas (age como se fosse a única)


32


DURABILIDADE – Ao final da confirmação dos dados, estes persistem, mesmo com falhas no sistema.


33

Exemplo:

A transação Ti está alterando um dado X

A transação Tj está excluindo o dado X

ISOLAMENTO


34

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


35

Exemplo:Em uma transação Ti, havia:

beginread(A)A:=A+50;write(A)commit;

Se houver erro no commit, nada é feito

ATOMICIDADE


36

Exemplo:Em uma transação Ti, havia:

beginread(A)A:=A+50;write(A)commit;

A tinha um valor 100. Agora tem 150.

CONSISTENCIA

Resumo

37

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

Resumo

38

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

Resumo

39

Concorrência:

10) Write de Thomas

11) Protocolo baseado em validação

Protocolo Granularidade Múltipla

40

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)


41

BD

A1

A2

Fa

Fb

Ra1

Ra2

Ra3

Fc

Rb3

Rc1

...RcN

Banco de dados

Área de dados

Arquivo (tabela)

Registro

Lock A2A2

Fc

Rc1

RcN

Copiar no quadro

(bloqueio explícito ximplícito)


42

BD

A1

A2

Fa

Fb

Ra1

Ra2

Ra3

Fc

Rb3

Rc1

...RcN

Banco de dados

Área de dados

Arquivo (tabela)

Registro

Lock A2A2

Fc

Rc1

RcN

Copiar no quadro

(bloqueio explícito ximplícito)


43

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 ?


44

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.


45

Bloqueios de intenção

AncestraisIS – Intention Shared – Compartilhado de intençãoIX – Intention Exclusive – Exclusivo de intençãoSIX – Shared e Intention Exclusive – Compartilhado e exclusivo de intenção

NósX – Exclusive – ExclusivoS – Shared – Compartilhado


46

Matriz de compatibilidade de Bloqueios de intenção

IS IX S SIX X

IS true true true true false

IX true true false false false

S true false true false false

SIX true false false false false

X false false false false false


47

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

T1 T2 T3 T4

Read (Ra1)Write (Ra2)

Read(Fa)Read (DB)


Como ficam os bloqueios no Schedule abaixo ?

Protocolos baseados em Granularidade múltipla

49

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

Protocolos baseados em Granularidade múltipla

50

Características


Previne deadlock ?



Sim

Não

Não

Sim

Protocolos baseados em Múltipla versão

51

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 ?


52

Mantendo cópias de dados Q, com timestamp

Assegurando a seriação

De forma rápida

Timestamp (TS) associado

Históricos de Q


53

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 QkR-timestamp (Qk) – é o MAIOR timestamp de qualquer transação que leu com sucesso a versão Qk


54

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 T2read(A);A = A*1.50;write(A);

read(A);


55

RegrasTi é 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


56

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


57

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


58

Características


Previne deadlock ?



Sim

Não

Não

Sim

O problema do impasse (deadlock) na concorrência

59

Deadlock

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


60

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


61

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


62

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


63

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


64

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)


65

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.


66

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.


67

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)


68

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)


69


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.


70


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


71

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


72

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 impasseTempo curto → excesso de rollbacks mesmo sem impasse


73

Detecção e recuperação de impasse

Deve-se usar um protocolo que impeça o deadlock OUGerenciá-lo quando ocorrer.

No último caso, um algortimo está sempre checando o status do sistema, para detectar deadlocks


74

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


75

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


76

Detecção de impasse – gráfico de espera

Um algoritmo fica percorrendo de tempos em tempos a estrutura do gráfico (mantida pelo SGBD), à procura de impasse

Como é a leitura deste gráfico ?


77

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


78


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


79


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 ?


80

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.

Operações de inclusão/exclusão

81

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


82

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 okb) Se vier depois, Tj terá erro lógico

a) Se Ij vier antes de Ii, Tj terá erro lógicob) Se vier depois, Tj terá erro lógico


83

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.


84

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.


85

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)

O fenômeno fantasma

86

Considere as transações:

T29 T30Select sum(saldo)From contasWhereAgencia = 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

O fenômeno fantasma

87

O conflito existe sem haver nenhuma tupla em comum !

Conta Agencia Saldo Bloq. T29

1 1001 100 Sim

2 1001 500 Sim

3 1001 550.17 Sim

4 17 100.00 Não

Bloqueio de índice, para evitar este problema

UNDB

BANCO DE DADOS II

Prof. Alessandro Gonç[email protected]

88

UNDB

Documents

Transcript of UNDB