Captulo 2 do Material didtico de:

CARVALHO, Tanisi,. e VICARI, Simone. Projeto de Banco de Dados.

2 Controle de Concorrncia
O controle de concorrncia a atividade de coordenar a ao de processos que
operam em paralelo, acessam dados compartilhados e, portanto, interferem uns com os
outros.
Quando duas ou mais transaes executam concorrentemente, suas operaes podem
ser processadas, pelo sistema de computao, de forma intercalada (interleaving). A
Figura 2-1 apresenta um exemplo da execuo serial das transaes T1, T2 e T3 e da
execuo interleaving das mesmas transaes.

T1
T1

T2

T2
T3

T1

T3
T2

T1

tempo

Figura 2-1: Exemplos de execues das transaes T1, T2 e T3

A execuo concorrente das transaes permite um melhor aproveitamento dos
recursos do sistema. A execuo de uma transao geralmente envolve operaes de E/S
liberando o uso da CPU, tornando-a ociosa. Esse tempo de CPU pode ser destinado
execuo de outra transao. A idia central manter em paralelo o processamento da
E/S e da CPU melhorando, assim, o throughput do sistema (nmero de transaes
executadas por unidade de tempo).
Um outro aspecto que em um sistema podem existir transaes longas e transaes
curtas. Se a execuo for seqencial, ento pode ocorrer da transao curta ter que
aguardar pela transao longa acarretando em um tempo de resposta maior (tempo que
uma transao leva para comear a responder solicitao realizada). A Figura 2-1
apresenta um exemplo dessa situao, a transao T3 tem que aguardar a execuo de T1
e T2; j na execuo interleaving, o tempo de T3 melhorado.
Na Figura 2-2 temos a arquitetura do SGBD do ponto de vista de gerncia de
transaes:

gerente de transaes: executa as operaes do banco de dados e das

transaes, passando-as para o scheduler;
scheduler: controla a ordem da execuo das operaes read, write, commit e
abort de diferentes transaes que so executadas, garantindo o isolamento. As

aes do scheduler podem ser: executar, rejeitar ou postergar a operao que

chega para o scheduler;
gerente de recuperao: responsvel pela finalizao das transaes (garante a
atomicidade e a durabilidade);
gerente de buffers: armazena parte do banco de dados em memria durante a
execuo das transaes. responsvel pela tansferncia dos dados entre o
disco e memria principal.
T1

T2

T3

....

Tn

Gerente de
Transaes
Scheduler
Gerente de Dados

Gerente de
Recuperao
Falhas
Gerente de
Buffers

Banco de Dados
/LOG

Figura 2-2 Gerncia de Transaes

2.1 Problemas associados execuo concorrente de TAs

Quando se tem transaes executando concorrentemente pode-se levar o banco de
dados a um estado inconsistente.
Problemas que podem existir sem um mecanismo de controle de concorrncia:
Atualizao perdida: ocorre quando uma atualizao de uma transao
sobreescrita pela atualizao de outra transao, fazendo com que uma delas seja
perdida;

a) execuo serial
T1
read(x)
X=x-10
write(x)
read(y)
Y=y+10
write(y)
commit

b) execuo no serial
T1
T2
read(x)
x=x-10
read(x)
x=x+100
write(x)
Commit
write(x)
read(y)
y=y+n
write(y)
commit

T2
read(x)
x=x+100
write(x)
commit

TAs no recuperveis:
Uma transao no pode se basear em dados de uma transao que ainda no foi
efetivada (princpio da recuperabilidade).
T3
read(x)
x=x-10
write(x)

T4

read(x)
x=x+100
write(x)
commit
read(y)
rollback

T4 considerou T3
concluda com
sucesso o que no
verdadeiro!!!

2.2 Teoria da Serializabilidade

O sistema de banco de dados deve garantir que a execuo de transaes
concorrentes levem o banco de dados de um estado inicial consistente para outro final,
tambm consistente.
A execuo de um conjunto de transaes dita serializvel, se e somente se, ela
produz os mesmos resultados no BD que alguma das possveis execues seriais deste
mesmo conjunto de transaes.
A teoria da Serializabilidade uma ferramenta matemtica que nos permite verificar
se um mecanismo de controle de concorrncia (scheduler) trabalha corretamente.
A histria um modelo matemtico utilizado pela teoria da serializabilidade para
representar a execuo concorrente de um conjunto de transaes.

O conceito de schedule ajuda a identificar as execues que garantem a

consistncia do banco de dados
Os schedules podem ser:

seriais: o schedule em que as operaes de cada transao so executadas

consecutivamente, sem qualquer intercalao das operaes das transaes;
no seriais: nesse tipo de schedule as operaes das transaes so executadas
de forma intercalada.

O objetivo da serializabilidade encontr,ar um schedule no serial que produza os

mesmos resultados que a execuo dos schedules seriais desse conjunto de transaes.
Para analisar um schedule considera-se apenas as operaes de leitura (r), escrita (x),
commit (c) e abort (a) (Ordenao das opees conflitantes.
Um schedule ou histria da transao:

Quando duas (ou mais) transaes so executadas concorrentemente, a ordem

de execuo das operaes de cada transao formam a Histria da transao;
representa a ordem cronolgica em que as transaes so executadas;
a ordem em que as operaes aparecem em cada transao individual deve ser
preservada.

Exemplo:
Histria Ha: r1(X); w1(X); r1(Y); w1(Y); c1; r2(X);w2(X); c2;
Histria Hb: r2(X);w2(X); c2; r1(X); w1(X); r1(Y); w1(Y); c1;
Histria Hc: r1(X); w1(X); r2(X);w2(X); r1(Y); w1(Y); c1;c2
2.2.1 Situao de conflito em uma Histria
Existe um conflito se duas operaes pertencem a transaes diferentes e fazem
acesso ao mesmo dado x e uma das operaes um write(x).
Conflitos em Hc: r1(X) e w2(X); r2(X) e w1(X); w1(X) e w2(X);
No so conflitantes em Hb:

operaes de read: r1(X) e r2(X)

operaes em dados diferentes: w2(X) e w1(Y)

Operaes conflitantes:
Ti(read(X)) e Tj(write(X)): Se Ti vier antes de Tj, ento Ti no l o valor escrito
por Tj.
Ti(write(X)) e Tj(read(X)): Se Ti vier antes de Tj ento Tj vai ler os valor escrito
por Ti.
Ti(write(X)) e Tj(write(X)): O prxima valor de read(X) ser afetado pela ordem
de execuo de Ti e Tj, pois s o ltimo valor vai permanecer.

Uma Histria ainda apresenta a possibilidade de execues incompletas de

transaes (pode ter transaes ativas).
Histria Completa: no contm transaes ativas; h um Commit ou Abort para cada
transao da Histria.
2.2.2 Serializabilidade de uma Histria
Execuo serial de T1 e T2 (sem intercalao):

so executada todas as operaes de T1 e aps todas as de T2;

ou, so executadas todas as operaes de T2 e aps todas as de T1.

a)

b)
T1

T2

T1

Read(X)
X:=X*1.1
Write(X)
Read (Y)
Y:= Y+20
Write(Y)

T2
Read(X)
X:= X+100
Write(X)

Read(X)
X:=X*1.1
Write(X)
Read (Y)
Y:= Y+20
Write(Y)

Read(X)
X:=X+100
Write(X)

Uma histria H dita serial se, para cada duas transaes Ti e Tj ou todas as
operaes de Ti aparecem antes de Tj ou vice-versa, logo:

so sempre corretas;
no h interferncia de outras transaes;
limitam a concorrncia, pois no possvel fazer o escalonamento da CPU
entre as transaes;

Nas histrias no seriais as operaes das transaes so intercaladas.

c)

d)
T1

T2

Read(X)
X:=X*1.1
Write(X)

T1

T2

Read(X)
X:=X*1.1
Read(X)

Read(X)
X:= X+100

X:= X+100
Write(X)
Read (Y)
Y:= Y+20
Write(Y)

Write(X)
Write(X)
Read(Y)
Y:= Y+20
Write(Y)

Um histria H serializvel se e somente se sua execuo equivalente a uma das

possveis execues serias deste conjunto de transaes.

2.2.3 Definio da equivalncia entre histrias

A equivalncia entre histrias:

definida sobre um mesmo conjunto de transaes e possui as mesmas

operaes;
as operaes conflitantes devem estar ordenadas na mesma forma nas duas
histrias.

No exemplo: a histria c equivalente a execuo serial a. Nas duas histrias,

read(X) de T2 l o valor de X escrito por T1, as outras operaes de read lem os valores
a partir do banco de dados. T1 a ultima transao a gravar o item Y e T2 a ltima
transao a gravar X nas duas histrias. Como a uma historia serial e c
equivalente a a, ento c uma histria serializvel.
2.2.4 Teste da serializabilidade de uma histria
A verificao da serializabilidade de uma histria H feita atravs de um Grafo de
Precedncia ou Grafo de Serializabilidade:

os ns so as transaes que terminaram com sucesso

as bordas (ou elos) consistem em todas as bordas Ti
Tj para qual uma das
trs condies so vlidas:
Ti executa um write(X) antes que Tj execute read (X)
Ti executa read (X) antes que Tj execute write (X)
Ti executa write (X) antes que Tj execute write (X)

A Histria serializvel se, e somente se, no houver ciclos no grafo.

Grafo de precedncia para a Histria A:

X
T1

T2

Grafo de precedncia para a Histria C:

X
T1

T2

Uma histria serializvel aproveita os benefcios da execuo concorrente mantendo

a correo dessas transaes. Na prtica, difcil testar a serializabilidade de uma
histria:

a intercalao das operaes numa execuo concorrente determinada pelo

scheduler do sistema operacional e os critrios do prprio SO, como
prioridade, carga do sistema, tempo em que uma transao foi submetida,
interferem na ordenao dessas transaes;
praticamente impossvel determinar de antemo a ordem de intercalao;
no prtico executar as transaes aleatoriamente, testar a serializabilidade e
cancelar os efeitos das histrias que no so serializveis;
a maioria dos sistemas utiliza mtodos que garantem a serializabilidade sem ter
que fazer testes aps a execuo das transaes.
Estes mtodos determinam protocolos que cada transao individual deve
seguir para garantir a serializabilidade de todas as histrias nas quais a
transao participa.

2.3 Mecanismos para Controle de Concorrncia

Os mecanismos de controle de concorrncia tm por objetivo permitir a
concorrncia garantido o princpio da serializabilidade. Sero estudados trs
implementaes de mecanismos de controle de concorrncia:

marcas de tempo (timestamp);

verses.
bloqueios (locking);

2.3.1 Mecanismo de Marcas de tempo (Timestamps)

Os mecanismos baseados em marcas de tempo no envolvem bloqueios, portanto
no h deadlocks. Caracterizam-se por uma marca de tempo (timestamp) que um
identificador nico criado pelo SGBD que indica o momento em que a transao
comeou e que o sistema se utiliza para identificar a ordem de execuo das operaes.

Um timestamp associado transao no momento em que ela inicia. A gerao do

timestamp pode ser a partir do clock do sistema quando a transao comea ou atravs de
um contador lgico incrementando a cada incio de transao.
Regra do protocolo:

ordenar as transaes de tal modo que as transaes mais antigas, com

timestamps menores, tenham prioridade caso haja um conflito. Timestamp
Ordering (TO).
Se a ordem dos timestamps for violada, a transao T estar violando a
serializabilidade do schedule. T dever ser abortada e reinicializada com novo
timestamp.

Segue abaixo o detalhamento do algoritmo:

Timestamp de uma transao: TS(T)

Cada item do banco de dados possui dois valores de timestamp:
 read_TS(X): timestamp da ltima transao que leu X com sucesso
 write_TS(X): timestamp da ltima transao que gravou X com sucesso.

Para uma transao T com timestamp TS(T):

1. Ti emitiu um Read(X):
Se TS(Ti) < write_TS(X) Ento Ti tenta ler um valor que foi gravado por uma
transao que comeou depois. Os valores que Ti leu provavelmente esto
inconsistentes. Ti abortada e reinicalizada com novo timestamp
Seno TS(Ti) >= write_TS(X): Read(X) executada e read_TS(X) ajustado para
o maximo( TS(Ti), read_TS(x));
2. Ti emitiu um Write(X):
Se TS(Ti) < read_TS(X) ou TS(Ti) < write_TS(X) Ento Ti abortada e
reinicializada com novo timestamp.
Uma transao iniciada aps Ti j utilizou dado X para uma leitura ou gravao. Ti
no pode atualizar o dado agora. Ou seja, Ti est " atrasada" para gravar o dado e
uma transao mais nova (que comeou depois) j leu ou atualizou o dado.
Seno Write(X) executada e write_TS(X) ajustado para TS(Ti).

A maior desvantagem dessa tcnica o fato de ter que desfazer as transaes e

reinicializ-las. No caso de transaes longas, por exemplo, o desempenho da execuo
das transaes pode cair consideravelmente. Uma TA desfeita pelo controle de
concorrncia recebe um novo Timestamp e reiniciada.

Exemplos:
a) Scheduler Serializvel
Ti
Read(A)
Write(A)

Ti
A
R_TS
W_TS

Read(A)
Write(A)
Read(B)
Write(B)

B
Read(B)
Write(B)

R_TS
W_TS

b)Scheduler No-serializvel
Ti
Read(A)

Tj
A
Read(A)
Write(A)
Read(B)

Write(A)
Read(B)
Write(B)

R_TS
W_TS
B
R_TS
W_TS

Write(B)

2.3.2 Mecanismo de Multiverso

Os esquemas de controle de concorrncia discutidos at agora asseguram a
seqncia tanto pelo retardo de uma operao como pelo aborto da transao que
solicitou a operao.
Em um esquema multiverso, cada operao de write sobre um dado x cria uma
nova cpia (verso) de x. Cada operao de read seleciona uma verso de x, garantindo
com isso a serializabilidade. Geralmente os esquemas multiverso so implementados
atravs da tcnica de marcadores de tempo (timestamps).
Assim, cada item de dado x possui uma seqncia de verses (x1, x2, x3, ...,xn).
Sendo que cada verso apresenta trs campos:

contedo: valor da verso do item de dado xi;

write_TS(xi): TS da transao que leu a verso de xi com sucesso;
read_TS(xi): maior TS da transao que leu a verso xi com sucesso.

Se uma transao Ti executa uma operao:

Read(x): busca-se a verso xi com o maior TS que seja menor ou igual a TS(Ti). O
campo read_TS(xi) atualizado com o valor de TS(Ti), caso read_TS(x) < TS(Ti);

Write(x): busca-se a verso xi com o maior TS que seja menor ou igual a TS(Ti). Se
TS(Ti) < read_TS(xi), ento Ti desfeita; caso contrrio, uma nova verso de x criada
e os valores de read_TS(xi) e write_T S(xi) so inicializados com TS(Ti).
Algumas transaes podero ter o seu commit postergado, por exemplo, se TS(xi) <
TS(xj), ou seja, a transao j se baseou na verso de x da transao i, ento tj s poder
concluir com sucesso (commit) aps o trmino de ti.
O esquema apresenta as seguintes vantagens:

operaes de read no so rejeitadas;

evita a ocorrncia de deadlock
garante a serializabilidade.

Como desvantagens podemos destacar:

espao adicional para manter as verses

leituras de um dado x requerem a atualizao do campo read_TS(x) o que
requer acessos a disco adicionais
conflitos (entre operaes) so resolvidos atravs de repeties ao invs de
esperas, o que pode ser bem caro para o sistema.

2.3.3 Bloqueio simples

Consiste em estabelecer bloqueios sobre o dado a ser acessado pela transao, de
modo a restringir o acesso a este dado.
A unidade de bloqueio, geralmente, a de registro. Quanto menor for a
granularidade de bloqueio, maior o grau de concorrncia.
So definidos dois tipos de bloqueios:

Exclusivo (E): se uma transao obteve um bloqueio E em um dado, ento a

transao pode ler e escrever neste dado.
Compartilhado (C): se uma transao obteve um bloqueio C em um dado, esta
transao e as demais podem somente ler este dado

Matriz de Compatibilidade de Bloqueios:

C
E

C


X

E
X
X

Quando uma transao Ti deseja acessar um dado, ela deve primeiro bloque-lo com
um dos dois tipos de bloqueio, dependendo da operao desejada. Se o dado j est
bloqueado com tipo incompatvel, Ti precisa esperar at que todos os bloqueios
incompatveis sejam liberados.
To logo o dado deixe de ser utilizado o bloqueio deve ser liberado.
T1
lock_E(x)
read(x)

x=x-1
write(x)
unlock(x)

T2

lock_E(x)
espera
...
...
...
lock_E(x)
x=x+100
write(x)
unlock(x)

Um dos problemas associados a este protocolo o fato dos bloqueios serem

liberados muito cedo. Observe o exemplo abaixo:
T3

T4
sum=0
lock_C(x)
read(x)
unlock(x)
sum=sum+x
lock_C(y)

lock_E(x)
x=x-10
write(x)
unlock(x)
commit
read(y)
unlock(y)
sum-sum+y

O protocolo de bloqueio simples no garante o isolamento por completo. No

exemplo acima, caso T4 seja abortada T3 foi efetivada com valores de x que no
existiram no banco de dados (atomicidade para T4).
2.3.4 Bloqueio de Duas Fases (2PL)
O mecanismo de bloqueio de duas fases (Two-Phase Lock), garante a
serializabilidade tratando os bloqueios em duas fases:

fase de aquisio (growing phase): nesta fase a transao apenas adquire os

bloqueios;
fase de liberao (shrinking phase): nesta fase a transao somente libera
bloqueios. A partir do momento que o primeiro bloqueio liberado nenhum
bloqueio pode ser adquirido pela transao.

O Strict 2PL garente execues concorrentes serializveis, recuperveis, evita o

cascating abort e liberando os bloqueios apenas no commit ou rollback.
O mecanismo funciona de forma anloga ao mecanismo de bloqueios simples,
diferenciando-se apenas pela forma como so tratadas a aquisio e a liberao de
bloqueios.
T1
read(x)
x=x-10

T2

T1
Lock_E(x)
x=x-10

T2

read(x)
x=x+100
write(x)
commit
write(x)
read(y)
y=y+10
write(y)
commit

lock_E(x)
espera
...
...
...
...
...
...
...
...
...
continua ...

write(x)
lock_E(y)
read(y)
y=y+10
write(y)
commit
unlock(x,y)

A implementao do mecanismo 2PL tem algumas variaes conforme mostra a

Figura 2-3. As variaes caracterizam-se pela forma como so implementadas as fases de
aquisio e liberao de bloqueios.

2PL Estrito

2PL Bsico

BOT

EOT

BOT

2PL Conservativo

EOT

BOT

EOT

Figura 2-3: Variaes do mecanismo 2PL

Na verso 2PL Bsico, os bloqueios so liberados medida que a transao deixa de
utiliz-los. Isso pode acarretar num problema conhecido como aborto em cascata
(cascading abort). Uma vez que o bloqueio foi liberado, este dado pode ser utilizado por
qualquer outra transao, assim se a transao no concluir com sucesso, outras
transaes tero se baseado em um dado intermedirio levando a uma inconsistncia do
banco de dados.
A implementao estrita resolve esta situao liberando os bloqueios apenas no final
e em um momento nico, garantindo com isso que o problema de aborto em cascata no
ocorra. Esta implementao pode ter ainda uma otimizao, permitindo que os bloqueios

compartilhados sejam liberados deixando apenas os bloqueios exclusivos. A

implementao estrita a mais utilizada comercialmente.
Uma caracterstica dos protocolos baseados em bloqueios so as situaes de
impasse (deadlocks). Uma situao de impasse ocorre quando uma transao est a
espera de um dado que est bloqueado por uma segunda transao e esta est a espera de
um dado segurado pela primeira. As situaes de deadlock so indesejveis, pois
degradam o desempenho. Este assunto ser detalhado na prxima sesso.
A implementao conservativo evita que o deadlock ocorra, pois solicita todos os
dados de antemo. Esta abordagem, no entanto, tende a diminuir o throughput do
sistema, visto que uma transao no vai utilizar todos os dados ao mesmo. Alm disso,
difcil saber quais dados sero utilizados por uma transao. Esta implementao pode
levar a outro problema conhecido como postergao definida, situao em que uma
transao fica a espera de um evento que nunca venha a ocorrer.
Uma outra caracterstica dos protocolos de bloqueios que alguns sistemas
permitem iniciar o bloqueio como compartilhado e depois passar este bloqueio para o
modo exclusivo (lock upgrade/downgrade). A vantagem disso que pode-se retardar a
aquisio de bloqueios no modo exclusivo, permitindo assim um maior grau de
concorrncia. Tanto para o upgrade ou downgrade a matriz de compatibilidade de
bloqueios deve ser obedecida. Isso pode acarretar em situaes de deadlock.

2.4 Deadlock
Uma situao que pode ocorrer em sistemas concorrentes conhecida por impasse
ou deadlock (abrao mortal). O deadlock est associado a utilizao de recursos
compartilhados que s podem ser utilizados de forma exclusiva, no caso de banco de
dados, os dados utilizados pelas transaes.
Um sistema est em deadlock sempre que uma transao Ti est esperando por um
item de dado que est bloqueado por uma transao Tj e Tj est esperando por um item
de dado que est bloqueado por Ti.
H dois mtodos para resolver um deadlock:

utilizar alguma tcnica que evite a sua ocorrncia;

possuir mecanismos para deteco e recuperao de deadlock.

2.4.1 Preveno de Deadlock

H duas abordagens para a preveno de deadlock. Uma garante que nenhum ciclo
de espera poder ocorrer pela ordenao de solicitaes de bloqueio, ou pela aquisio de
todos os bloqueios juntos. A outra faz com que a transao seja refeita, em vez de esperar
por um bloqueio, sempre que a espera possa potencialmente decorrer em deadlock.
Pela primeira abordagem, cada transao obrigada a bloquear todos os itens de
dados antes de sua execuo. Alm disso, ou todos os dados so bloqueados de uma s

vez ou nenhum ser. H duas desvantagens nesse protocolo: a dificuldade de prever,

antes da transao comear, quais itens de dados devero ser bloqueados. Segundo, a
utilizao do item de dado pode ser bastante reduzida j que os dados podem ser
bloqueados e no ser usados por um longo perodo de tempo.
Pela segunda, so utilizados timeouts para decidir se uma transao deve ficar em
wait ou deve ser refeita (REDO). Se o tempo de espera ultrapassar um valor x, a
transao abortada independente de ter ocorrido o deadlock ou no.
2.4.2 Deteco e Recuperao de Deadlock
As tcnicas de deteco e recuperao so utilizadas quando o subsistema de
controle de concorrncia no possui nenhum mecanismo de preveno de deadlock.
Normalmente a deteco feita pela gerao de um grafo de espera, onde a ocorrncia de
ciclos indica a presena de deadlock.
Para recuperar do deadlock necessrio que uma ou mais transaes sejam
selecionadas como vtimas para serem abortadas. Para a seleo das vtimas podem ser
utilizados critrios como, por exemplo, a transao mais recente, o quanto falta para uma
transao terminar, quantas atualizaes a transao realizou ou at mesmo nenhum
critrio (por facilidades de implementao).
Um problema decidir quando o algoritmo de deteco deve ser acionado. Se os
intervalos forem curtos, muito overhead. Se forem intervalos longos, pode-se levar muito
tempo para verificar que um deadlock ocorreu.
Grafo de espera:

criado um n para cada transao do sistema

se Ti est esperando por um dado utilizado por Tj, criada uma borda Ti Tj
quando o dado liberado, a borda removida
ocorre um dealock quando o grafo contiver um ciclo

T1

T2

2.5 Granularidade Mltipla

Os exemplos de bloqueios apresentados at agora se referiam a bloquear um registro
por vez. Existe, porm, situaes em que vantajoso bloquear diversos itens de dados,
tratando-os como uma unidade de acesso do que bloquear um registro. Por exemplo:

atualizao de todos os dados de um arquivo;

leitura de todos os dados do banco de dados;

Nessas situaes mais interessante bloquear todo o arquivo, pois em uma nica
solicitao todo o arquivo estar bloqueado e o tempo necessrio para realizar os bloqueios
(de cada registro) evitado. Em contrapartida, se a transao necessita de apenas um
registro, bloquear todo o arquivo desnecessrio e, tambm, elimina a concorrncia.
importante, ento, que o sistema permita definir mltiplos nveis de granularidade
de bloqueio. A granularidade de bloqueio , ento, a poro de itens de dados que pode ser
bloqueada por uma transao. As granularidades mais usuais so:
registro (tupla);
pgina;
arquivo (tabela).
Isso pode ser implementado atravs de uma rvore de granularidade, onde cada
nodo representa a poro de dados (gro) que est sendo bloqueada e existe uma hierarquia
entre os nodos. Observe a Figura 2-4:

BD

A2

A1

Arq a

ra1

...

Arq b

ran

rb1

...

Arq c

rbn

rc1

...

rcn

Figura 2-4: rvore de Granularidades

Um banco de dados (BD) pode ser dividido em reas (A). Cada rea pode ser
dividida em um ou mais arquivos e cada arquivo possui um ou mais registros.
Princpio do bloqueio de gros:

quando uma transao bloqueia um determinado gro (ou nodo), ela bloqueia
tambm todos os nodos filhos deste gro no mesmo modo de bloqueio;
quando uma transao bloqueia um gro, todos os seus ancestrais devem ser
bloqueados intencionalmente no mesmo modo de bloqueio.

Modos de bloqueio:

compartilhado (C): o nodo e toda a sua subrvore esto bloqueados

explicitamente no modo compartilhado;
exclusivo (E): o nodo e toda a sua subrvore esto bloqueados explicitamente
no modo exclusivo;

compartilhado intencional (CI): um nodo com este bloqueio significa que

algum bloqueio compartilhado explcito est sendo mantido na sua subrvore;
exclusivo intencional (EI): um nodo com este bloqueio significa que algum
bloqueio exclusivo explcito est sendo mantido na sua subrvore;
compartilhado e exclusivo intencional (EI): um nodo est bloqueado
explicitamente no modo compartilhado e algum nodo na sua subrvore est
bloqueado explicitamente no modo exclusivo;

CI

EI

CEI

CI

EI

CEI

Regras:
1) respeitar a matriz de compatibilidade dos modos de bloqueio
2) a raiz da rvore precisa ser bloqueada primeira e pode ser bloqueada em
qualquer modo
3) um nodo n pode ser bloqueado por Ti no modo C ou CI apenas se os pais de n
esto correntemente bloqueados por Ti no modo EI ou CI
4) Um nodo n pode ser bloqueado por Ti no modo E, CEI, ou EI apenas se os pais
de n esto correntemente bloqueados por Ti no modo EI ou CEI
5) Ti pode bloquear um nodo apenas se ele no desbloqueou nenhum nodo antes
(segue a tcnica de bloqueio de duas fases)
6) Uma Ti pode desbloquear um nodo apenas se nenhum dos filhos estiver
bloqueado por Ti.
O protocolo de granularidade mltipla exige que os bloqueios sejam feitos de cima
para baixo (top-down da raiz para as folhas), enquanto a liberao deve ser de baixo para
cima (bottom-up das folhas para a raiz).
Esse protocolo aumenta a concorrncia e reduz o overhead por bloqueio. Isso
particularmente til em aplicaes que misturam:

Transaes curtas que mantm acesso em poucos itens de dados;

Transaes longas que produzem relatrios a partir d eum arquivo ou de um

conjunto de arquivos.

Os seguintes fenmenos podem ocorrer:

leitura suja (dirty reads): ocorre quando uma transao tem acesso aos dados
modificados por uma transao que ainda no concluiu, ou seja, a transao est
acessando dados intermedirios.
Leituras no repetidas (Nonrepeatable Read): A TA faz a mesma consulta em
vrios momentos e encontra valores diferentes que foram modificados ou deletados.
Leitura fantasma (Phantom reads): A TA faz a mesma consulta com uma
determinada condio que retorna um conjunto de valores, esta mesma consulta
executada novamente e retorna mais linhas, que foram adicionadas por TAs commited e
que satisfazem a condio.
Bibliografia utilizada no captulo:
[BER 87] BERNSTEIN, Philip A; HADZILACOS, Vassos; GOODMAN, Nathan. Concurrency Control
and Recovery in Database Systems. Reading:Addison-Wesley, 1987.
[CON 98] CONNOLLY, Thomas; BEGG, Carolyn. Database Systems a practical approach to design,
implementation and management. Harlow:Addison-Wesley, 1998.
[IOC 95] IOCHPE, Cirano. Notas de Aula CMP97 Sistemas de Banco de Dados. Curso de PsGraduao em Cincia da Computao, 1995.
[SIL 99] SILBERSCHATZ, Abraham.; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de
Dados. 3 edio., So Paulo: Makron Books, 1999.