CENTRO DE CINCIAS TECNOLGICAS DA TERRA E DO MAR

CINCIA DA COMPUTAO
BANCO DE DADOS
PROFESSOR MARCELO MAGNANI

CONTROLE DE CONCORRNCIA

Acadmico:
Maurcio Sonza

Itaja
Agosto/2014

Comeamos a aula de hoje com uma breve reviso da aula passada, aonde comentamos
sobre os conceitos de ACID, Grafo de Dependncia (Sobre e como gerar ele), Plano de
Execuo (Se ele serializvel ou no e como identificar isto).
1 - ACID:
A - Atomicidade: Significa que no pode ser dividida.
C Consistncia: Mostra que o dado consiste, seja ele antes ou depois de uma transao.
I Isolamento: Mostra que uma transao no pode infringir a outra enquanto estiver sendo
executada.
D Durabilidade: o armazenamento dos dados.
2 - Grafo de Dependncia: Gerado com base nos comandos das transaes expostas em
vertical e seguindo a regra;
L E
J E IL
E E
Se estas regras forem verdade, traado uma ligao de i->j.
3 - Dizemos que uma transao serializvel quanto ao conflito se obtivermos o mesmo
resultado das operaes se o resultado obtivo aps segurir a mesma em srie e alternando a
ordem for o mesmo.
A partir de agora comeamos o novo contedo, falando sobre a concorrncia, que nada mais
que uma regra aonde certas transaes no podem acessar os mesmos dados
simultaneamente, se no os dados podem ser alterados erroneamente, no garantindo a sua
consistncia.
Os problemas que podem ocorrer quanto ao problema causado pela concorrncia so:
1 Atualizao perdida
Exemplo: Ocorre quando um dado x escrito pela transao t1 e no salvo. Em seguida, a
transao t2 escreve este mesmo dado e tambm no salva. Aps este, a transao t1 solicita
salvar o dado escrito e t2 tambm, havendo assim a perda da informao repassada por t1,
visto que t2 a sobrescreveu.
2 Atualizao temporria
Exemplo: Ocorre quando um dado x foi escrito e salvo por t1, em seguida, o mesmo dado x
foi alterado e salvo por t2, porm, ao seguir a sequncia de t1, por alguma falha no comando
ou no sistema, foi necessrio efetuar um rollback, perdendo assim os dados que foram
modificados neste perodo.
3 Problema de sumrio incorreto
Ocorre quando os dados alterados em uma transao acabaram alterando o resultado final
porque no foram executados na ordem correta.
No exemplo apresentado na sala, a transao t3 realizada a soma de um acumulador mais a
varivel y antes dessa mesma varivel ter sido alterada e salva em t1 gerando assim uma
inconsistncia nos dados.
Para resolver este problema de concorrncia, devemos traar uma granularidade dos itens
compostos no banco de dados. considerado Grosso, quando houver menos concorrncia
para o SGBD gerenciar as operaes, o que no necessariamente bom, pois isso significa

que h outras transaes paradas na fila aguardando serem atendidas enquanto uma est
travando a maioria. considerado Fino, quando houve ainda mais operaes para o SGBD
gerenciar, o que bom, pois significa que o mesmo est tendo vrias requisies mas est
conseguindo atende-las, sem ter vrios usurios aguardando o fim de uma modificao.
Para auxiliar neste processo de concorrncia, devemos aplicar bloqueios no banco
dependendo da transao, so eles:
1 Bloqueio binrio
Um item no banco de dados possui apenas dois estados: bloqueado ou desbloqueado. Antes
de cada comando read/write, o dado deve ser bloqueado. Se um dado x estiver sendo
alterado em t1 e antes de ser desbloqueado for solicitado por t2 a alterao/acesso a este
dado, ser informado a requisio t2 que dever aguardar at que t1 termine as suas
alteraes.
2 Bloqueio Compartilhado/exclusivo
Um item no banco de dados possui agora trs estados: bloqueado para leitura, bloqueado
para escrita e desbloqueado. Antes de cada comando read/write a transao dever bloquear
o item de acordo com o que a operao ir realizar.
Chamamos de Promoo quando passado de um bloqueio de leitura (Read_lock) para
bloqueio de escrita (write_lock). Seu oposto chamado de Rebaixamento.
Um dado que esteja em read_lock poder ser lido por outra transao (vrios reads so
possveis), porm, ser bloqueado se um usurio solicitar uma alterao (write_lock).
Um dado que esteja atualmente em write_lock no poder ser lido/acesso por outro dado at
que este estado seja rebaixado.
Mesmo com tudo isso foi possvel concluir que os bloqueios no so suficientes para garantir a
segurana dos dados dos processos, para isto, devemos implementar o bloqueio de duas
fases, conhecido como 2PL Two Phase Locking.
Atravs deste a serializao das gravaes garantida, visto que a sua regra bsica diz que
todas operaes de bloqueio (read_lock e write_lock) devem ocorrer antes da primeira
operao de desbloqueio.
Chamados de Crescimento quando os dados esto sendo bloqueadas e de Encolhimento
quando os dados esto sendo liberados.
Existem trs tipos do 2PL, so eles:
1 2PL bsico: atende a prpria regra.
2 2PL Conservador (Menos utilizado): Alm de seguir a prpria regra, todos os dados devem
ser obtidos antes de iniciar as operaes de transao.
3 2PL Estrito (Mais utilizado): Alm de seguir a prpria regra, informa que todos os bloqueios
de escritas s sero liberados aps o termino da transao.
Com o uso do 2PL, ocorrem algumas situaes de deadlock e livelocks.
Deadlock: Ocorre um impasse. Um dado bloqueado por t1, as transaes t2 e t3 solicitam,
respectivamente, o seu acesso ao dado. Aps o dado ser liberado, isso no significa que o
dado ser liberado para t2, conforme ordem, visto que t3 pode ter uma prioridade maior e ser
atendida primeiro.

Pode ser programado para o sgbd criar uma rotina e verificar se este problema ocorre, porm,
envolve custo computacional.
Livelock : Semelhante ao Deadlock, ocorre um impasse, porm os dados no so bloqueados e
eles esto sendo processados pela CPU, porm ocorre lentido.