UNDB
BANCO DE DADOS II
Prof. Alessandro Gonçalves
[email protected]
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
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
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
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
Protocolo de árvore
Considerações
Todos os schedules legais são seriais de conflito
6
Protocolo de árvore
Cada Nó = lock-E(Dado)
A
B
C
F
D
G
E
H
I
...
J
7
Bloqueio de árvore
Características
Asseguram a seriação ?
Sim
Previnem deadlock ?
Sim
Previnem rollback em cascata ?
Não
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
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
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
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
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
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 ?
Ti quer ler um valor já atualizado por outro
2) Se TS(Ti) >= W-timestamp(Q), então a operação read
é executada. R-timestamp é atualizado.
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 ?
O valor que Ti produz foi necessário anteriormente
mas nunca seria produzido
2) Se TS(Ti) < W-timestamp(Q), rejeita e reverte Ti.
Ti quer atualizar um valor já atualizado por outro
Por que ?
3) Caso contrário, executa a operação e atualiza
W-timestamp
15
Protocolo ordenação por
timestamp
Reversão
Transação recebe um novo timestamp e reinicia
Exemplo anexo
16
Protocolo ordenação por
timestamp
Resumindo
Assegura a seriação ?
Sim
Previne deadlock ?
Sim
Previne rollback em cascata ?
Sim*
Starving pode acontecer
Sim
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
Protocolo Write de Thomas
Uma variação do Protocolo de ordenação por Timestamp
Considere o Schedule abaixo:
T1
read(A)
T2
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
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
Protocolo Write de Thomas
Resumindo
Gera schedules com seriação de visão
É uma especialização do protocolo ordenação por
timestamp
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
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
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
Protocolos baseados em
validação
Exemplo anexo
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).
Como Ti termina antes de Tj começar, a seriação é mantida.
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 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
Protocolos baseados em
validação
Características
Assegura a seriação ?
Sim
Previne deadlock ?
Sim
Previne rollback em cascata ?
Sim
Starving pode acontecer
Sim
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
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
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
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
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
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
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
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
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
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
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
Resumo
Concorrência:
10) Write de Thomas
11) Protocolo baseado em validação
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
Protocolo Granularidade Múltipla
B
D
Banco de dados
A
1
Área de dados
F
a
Arquivo (tabela)
Registro
A
2
R
a
1
R
a
2
F
b
R
a
3
Lock A2
F
c
R
b
3
Copiar no quadro
R
c
1
...
R
c
N
(bloqueio
explícito x
implícito)
41
Protocolo Granularidade Múltipla
B
D
Banco de dados
A
1
Área de dados
F
a
Arquivo (tabela)
Registro
A
2
R
a
1
R
a
2
F
b
R
a
3
Lock A2
F
c
R
b
3
Copiar no quadro
R
c
1
...
R
c
N
(bloqueio
explícito x
implícito)
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
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
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
Protocolo Granularidade Múltipla
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
46
X
false
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
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
Protocolos baseados em
Granularidade múltipla
Características
Assegura a seriação ?
Sim
Previne deadlock ?
Não
Previne rollback em cascata ?
Não
Starving pode acontecer
Sim
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
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
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
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
read(A);
A = A*1.50;
write(A);
T2
read(A);
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
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
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
Protocolos baseados em Múltipla
versão
Características
Assegura a seriação ?
Sim
Previne deadlock ?
Não
Previne rollback em cascata ?
Não
Starving pode acontecer
Sim
58
O problema do impasse
(deadlock) na concorrência
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
O problema do impasse
(deadlock) na concorrência
Detecção de impasse
Um gráfico direcionado, chamado gráfico de espera (waitfor) é 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
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
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
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
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
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
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
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
a) Se Ij vier antes de Ii, Tj terá erro lógico.
b) Se vier depois, ok
2 - Ij = write(Q) - update
a) Se Ij vier antes de Ii, Tj ok
b) Se vier depois, Tj terá erro lógico
3 - Ij = delete(Q)
a) Se Ij vier antes de Ii, Tj terá erro lógico
b) Se vier depois, Tj terá erro lógico
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:
a) Se Ij vier antes de Ii, Tj ok.
b) Se vier depois, terá erro lógico.
Se o dados Q EXISTISSE:
a) Se Ij vier antes de Ii, Tj erro lógico.
b) Se vier depois, ok.
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
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
O fenômeno fantasma
Considere as transações:
T29
Select sum(saldo)
From contas
Where
Agencia = 1001
T30
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
O fenômeno fantasma
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
87
UNDB
BANCO DE DADOS II
Prof. Alessandro Gonçalves
[email protected]
88