Tecnicas Controle Concorrencia

Sistema de Gerenciamento de Banco de Dados Tcnicas de Controle de Concorrncia
Cincia da Computao UFG Catalo/GO Prof. Mrcio Antnio Duarte
Controle de Concorrncia
Objetivo
Assegurar a propriedade de no interferncia ou isolamento das transaes executadas concorrentemente. A maioria das tcnicas assegura a serializao dos planos de execuo usando protocolos que garantem essa caracterstica.
Quatro conjuntos de protocolos: 1 - Bloqueios: bloqueiam os itens para impedir que outras transaes o utilizem; 2 - Timestamp (marcas de tempo): cria um identificador nico para cada transao; 3 - Multiverso: utilizam mltiplas verses de um item de dado; 4 - Protocolos otimistas: baseados em validao ou certificao;
Tipos de bloqueio: Bloqueio binrio - Pode assumir 2 estados: bloqueado e desbloqueado (1 ou 0); - Nos referimos ao valor do bloqueio de X como lock(X); - Duas operaes so usadas: lock_item e unlock_item;
Se o valor do lock em x 1, ento o item x no pode ser acessado por uma operao do Banco de Dados que requisita o item. Se o valor do Lock em x 0, ento o item x pode ser acessado quando requisitado. Uma transao requere acesso um item x usando uma operao lock_item(x). Se Lock(x) = 1, a transao forada a esperar. Quando a transao termina a operao envolvendo o item x, uma operao de unlock_item(x) usada, fazendo com que Lock(x) := 0 para que x possa ser acessada por outras transaes.
Operao Lock_item(X):
B: if lock_item(X) = 0 (desbloqueado) then lock(X) = 1 (bloqueado) else begin Wait (at que lock(X) = 0 e o Go to B End
gerenciador de bloqueio reinicia a transao)
Operao Unlock_item(X)
Lock(X) = 0;
O SGBD tem um subsistema gerenciador de bloqueio para manter e controlar o acesso aos bloqueios Ao se utilizar o bloqueio binrio toda transao devera obedecer as seguintes regras:
1. Uma transao T deve garantir a operao lock_item(X) antes de qualquer operao ler_item(X) ou escrever_item(X) seja executada em T; 2. Uma transao T deve garantir a operao unlock_item(X) depois que todas as operaes ler_item(X) e escrever_item(x) sejam completadas em T; 3. Uma transao T no resultar em uma operao lock_item(X) se ela j tiver o bloqueio no item X; 4. Uma transao T no resultar em uma operao unlock_item(X), a menos que ele j tenha o bloqueio no item X;
Bloqueio Compartilhado/Exclusivo
Desvantagens do bloqueio binrio: muito restritivo Deveria-se permitir a diversas transaes acessassem o mesmo item desde que fosse apenas para leitura. Se o item fosse acessado para escrita, o acesso deveria ser exclusivo de uma transao. Tais caractersticas podem ser implementadas pela tcnica de bloqueio mltiplo-modo, compartilhado/exclusivo ou de leitura/ escrita.
Neste esquema trs operaes de bloqueio so usadas: read_lock(X); write_lock(X); unlock(X). E existem trs estados possveis para o item de dados: read_locked; write_locked; unlocked.
Read_lock - ou tambm chamado de lock compartilhado, porque outras transaes podem ler o mesmo item. Write_lock tambm chamado de lock exclusivo, porque uma simples transao exclusivamente segura o lock de um determinado item.
Implementao - Bloqueio Compartilhado/Exclusivo
Um mtodo para implementar as operaes de bloqueio leitura/escrita manter o controle do nmero de transaes usar uma tabela de bloqueio para controlar o bloqueio compartilhado. Ex.:
Regras (Bloqueio Compartilhado/Exclusivo)
1. Uma transao T deve garantir a operao read_lock(X) ou write_lock(X) antes de qualquer operao ler_item(X) a ser executada. 2. Uma transao T deve garantir a operao write_lock(x) antes de qualquer operao escrever_item(x) ser executada; 3. Uma transao T deve garantir a operao unlock(x) depois que todas as operaes ler_item(x) e escrever_item(x) so completadas em T. 4. Uma transao T no vai gerar uma operao de read_lock(X) se ela j controlar um bloqueio de leitura ou um bloqueio de escrita no item X. 5. Uma transao T no resultar uma operao de write_lock(X) se ela j controlar um bloqueio de leitura ou um bloqueio de escrita no item X. 6. Uma transao T no resultar uma operao de unlock a menos que j controle um bloqueio de leitura ou um bloqueio de escrita no item X.
Operao de leitura - Bloqueio Compartilhado
B: if LOCK (X) = unlocked then begin LOCK (X) := read-locked; no_of_reads (X) := 1; end else if LOCK (X) = read-locked then no_of_reads (X) := no_of_reads (X) +1 else begin wait (until LOCK (X) = unlocked and the go to B; end;
lock manager wakes up the transaction);
Operao de escrita - (Bloqueio Exclusivo)
B: if LOCK (X) = unlocked then LOCK (X) := write-locked; else begin wait (at que LOCK(X) = unlocked go to B; end;
de locks acionar a transao)
e o gerenciador
Operao de unlock - (Desbloqueio)
if LOCK (X) = write-locked then begin LOCK (X) := unlocked; end else if LOCK (X) = read-locked then begin no_of_reads (X) := no_of_reads (X) -1 if no_of_reads (X) = 0 then begin LOCK (X) = unlocked; end end;
Converso de bloqueios
possvel entretanto relaxar um pouco as regras 4 e 5 permitindo a converso de um bloqueio: Promoo: transformar um bloqueio do tipo read_lock(X) em um bloqueio write_lock(X); Rebaixamento: transformar um bloqueio write_lock(X) em um bloqueio read_lock(X); do tipo
Garantindo Seriabilizao por Bloqueio de duas fases (2PL)
Este um protocolo de bloqueio em duas fases: Expanso: Novos bloqueios podem ser adquiridos, mas no podem ser liberados. Estreitamento: Os bloqueios existentes podem ser liberados, mas novos bloqueios no podem ser adquiridos.
Para garantir a serializao de transaes utiliza-se o bloqueio de 2 fases: Todas as operaes de leitura (read_lock) ou escrita (write_lock) devero ocorrer antes da primeira operao de desbloqueio (unlock) na transao. Primeira fase: operaes de leitura e escrita ou crescimento; Segunda fase: operaes de desbloqueio ou encolhimento Se houver converso de bloqueios: Promoo: dever ser feita durante a fase de crescimento; Rebaixamento: dever ser feita na fase de encolhimento;
Usar bloqueios binrios ou de leitura/escrita no garante a serializao
Ex: valores iniciais: X=20; Y=30
No exemplo anterior as transaes no obedecem ao bloqueio de 2 fases e por isso no so serializveis: T1: Depois da operao de unlock(Y) existe a operao de write_lock(X); T2: Depois da operao de unlock(X) existe a operao de write_lock(Y);
Exemplo de transaes que seguem o protocolo de 2 fases:
Mas no esto livres de deadlock!
Limitaes
O bloqueio em duas fases pode limitar a quantidade de concorrncia: A transao no poder liberar um item X depois de us-lo, caso tenha que bloquear um item Y; A transao deve bloquear um item Y antes que ela necessite dele, para que possa liberar X;
Variao do 2PL
2PL Conservativo ou Esttico Requer que uma transao lock todos seus itens antes que a execuo da transao inicie. um protocolo de dead_lock free 2PL Strict Uma transao T no libera quaisquer de seus locks at que ocorram seus commits ou aborts. No dead_lock free
Problemas com os Locks
DeadLock ocorre quando 2 ou mais transaes espera por um item que esteja bloqueado por alguma transao T' no conjunto. O que a transao poderia fazer? Bloquear uma transao e abort-la? A transao assumir e abortar a outra transao?
Tcnicas que evitam o dead lock
TimeStamp(ts) - identificador nico associado a cada transao; ordena o tempo das transaes. Tempo da transao mais velha < tempo de transao mais nova Duas tcnicas podem ser utilizadas: Wait_die (Esperar-morrer); Wound_wait (Ferir-esperar).
Wait-die: Se Ts(Ti) < Ts(Tj) - (Ti mais velha) ento Ti espera (wait) seno abort Ti e reinicia depois com o mesmo Ts Neste esquema uma transao mais velha permitido que ela espere, enquanto uma transao mais nova soliciantando um item controlado por uma transao mais velha abortada e reiniciada.
Wound-wait: Se Ts(Ti) < Ts(Tj) - (Ti mais velha) ento abort Tj seno Ti espera (wait) - (Ti mais nova) Um trasano mais nova permitido esperar, enquanto uma transao mais velha solicitando um item controlado por uma transao mais nova, apropria-se da transao mais nova, abortando-a.
Problemas tanto em Wait-die e Wound-wait?
Problemas tanto em Wait-die e Wound-wait? Ambas tcnicas abortam a transao mais nova; Podem causar aborts desnecessrios nunca iriam causar um dead_lock; Pode ocorrer vrias vezes, com Wait_die de Ti ser abortada e reiniciada vrias vezes, porque uma Tj mais velha continua a agarrar um item que Ti necessita.
Preveno de DeadLocks sem utilizao de Timestamp: No Waiting (sem espera): Se uma transao incapaz de obter um lock ela imediatamente abortada e reiniciada aps um certo tempo de espera sem checar se um dead lock ir ou no acontecer. Problema: pode causar muitas reinicializaes. Cautious Waiting (espera cuidadosa): Supondo que uma transao Ti tente bloquear X, que j est bloqueado por Tj, ento temos: Se Tj no est esperando por algum outro item bloqueado, ento Ti bloqueado e espera, caso contrrio, aborta Ti.
Outro protocolo de preveno de DeadLocks seria o Timeouts. Se uma transao espera mais do que o timeout, o sistema assume que a transao deadlock e a aborta indiferentemente se uma situao de deadlock realmente existe. Problema: se uma transao necessite de um tempo maior que o timeout para sua execuo ela nunca chegar ao seu fim, pois ela ser sempre abortada antes de seu trmino.
Outra tcnica de Deteco de Deadlock: Periodicamente o sistema checa as transaes para verificar se alguma delas est no estado de deadlock. Atravs do grafo WAIT-FOR, pode-se determinar quais transaes esto neste estado.
T1
T2
A forma de se determinar quando o sistema deveria checar pelo deadlock pode ser um problema. Critrios: - Nmero de transaes executadas concorrentemente; - O perodo de tempo em que vrias transaes esto esperando pelo lock de um item; Aps descobrir, o sitema dever abortar alguma transao. Este algortmo chamado de algortmo VICTIM. Ele deveria evitar a seleo de transaes: - Longas e com muitos updates; E tentaria selecionar as: - Mais envolvidas em deadlock.
Problema de Livelock Uma trasao est em livelock se ela no pode proceder por um perodo indefinido de tempo enquanto outras transaes no sistema continuam normalmente. Soluo: - Usar a fila FIRST_COME, FIRST_SERVE; - Permitir prioridades, aumentar a prioridade se a transao est esperando a mais tempo.
Problema de Starvation - Similar ao Livelock, ocorre nos algoritmos que tratam o deadlock se o algoritmo seleciona uma transao como VICTIM vrias vezes, isto acarretar ao seu abort infinitas vezes e nunca o seu trmino. Os esquemas WAIT_DIE e WOUND_WAIT evitam o starvation.
TimeStamp Ordenado (TO) - identificador nico associado a cada transao; ordena o tempo das transaes. Tipicamente, valores so atribuidos ao timestamp na ordem em que as transaes so submetidas no sistema. Timestamps podem ser gerados de diversas formas. Uma possibilidade usar um contador que incrementado a cada vez que uma transao busca um item. Neste esquema uma transao sequencialmente : 1, 2, 3, 4,... poderia ser numerada
Um problema que o contador de um PC tem um valor finito e por esse motivo o sistema periodicamente deve resetar o contador quando transaes no so executadas em um mesmo perodo curto de tempo. Um outro meio para implementar o timestamp o uso de um valor corrente do clock do sistema onde dois valores de timestamps iguais no podem ser gerados durante o mesmo "tick" do clock.
Timestamp (Ts)
O algoritmo deve garantir que, para cada item acessado por mais de uma transao na schedule, a ordem na qual o item acessado no deve violar a serialidade da schedule. Para isto, o TO associa com cada item do banco de dados dois Timestamp (Ts): 1 read_TS(x): assegura o timestamps das transaes read_item(x); 2 write_TS(x): assegura o timestamps das transaes write_item(x); maior timestamp entre todos os que tiveram sucesso em um maior timestamp entre todos os que tiveram sucesso em um
Timestamp Ordenado(TO)
O algoritmo TO compara o timestamp de uma transao T com o read timestamp e o write timestamp de x para garantir que a ordem de execuo da transao T no seja violada. Caso isso ocorra, ento a transao T precisa ser abortada e a transao dever sofrer um rollback. Assim, uma outra transao que tenha usado o valor escrito pela transao que foi abortada tambm dever sofrer um rollback, causando o efeito j conhecido de rollback em cascata.
Timestamp Ordenado(TO)
Soluo: O algoritmo de controle de concorrncia deve checar o timestamp das transaes nos seguintes casos:
1 Transao T emite uma operao escrever_item(x) se (read_TS(x) > TS(T)) ou (write_TS(x) > TS(T)) ento aborta T e faz um rollback de T seno executa escrever_item(x); TS(T) := write_TS(x); 2 Transao T emite uma operao ler_item(x) se write_TS(x) > TS(T) ento aborta T e faz um rollback de T seno se write_TS(x) <= TS(T) ento executa ler_item(x); TS(T) := read_TS(x); O TS dever ser sempre maior que read_TS e o write_TS para garantir a ordem de execuo da schedule.
Multiverso
Esta tcnica mantm no sistema verses de valores de itens antigos. Assim, quando uma transao escreve um item, ela escreve uma nova verso e a verso antiga do item retida. Desvantagem: ?
Multiverso
Esta tcnica mantm no sistema verses de valores de itens antigos. Assim, quando uma transao escreve um item, ela escreve uma nova verso e a verso antiga do item retida. Desvantagem: Necessrio mais espao de armazenamento
Multiverso baseada em TO
Aqui, vrias verses x1, x2, ..., xk de cada item de dado so mantidas pelo sistema.
Para cada verso, o valor da verso xi e os dois timestamps seguintes so mantidos: 1 read_TS(xi); 2 write_TS(xi); Se uma transao T pode executar uma operao escrever_item(x), uma nova verso xk+1 do item x criada, com ambos write_TS(xk+1) e read_TS(xk+1) para TS(T).
Multiverso baseada em TO
Para garantir a serializao, duas regras so usadas: 1 Se a transao T tenta executar uma operao escrever_item(x), e a verso i de x tem o mais alto write_TS(xi) de todas as verses de x, que tambm menor ou igual a TS(T), e read_TS(xi) > TS(T), ento ela aborta e reverte a transao T; caso contrrio, criar uma nova verso xj de x com read_TS(xj) = write_TS(xj) = TS(T). 2 Se a transao T tenta executar uma operao ler_item(x), encontra a verso i de x que tem o mais alto write_TS(xi) de todas as verses de x, que tambm menor ou igual a TS(T), ento retorna o valor de xi para a transao T e atualiza o valor de read_TS(xi) para o maior TS(T) e read_TS(xi) corrente.
Multiverso com Two-phase locking
Neste esquema existe trs modelos de locks para um item: 1 - read_lock(x); 2 - write_lock(x); 3 - certify_lock(x);
Lock normal:
Read Read Write Sim No Write No No
Multiverso Two_phase locking:

Read Read Write Certify Sim Sim No Write Sim No No Certify No No No
Neste esquema, leituras podem proceder concorrentemente com operao de escrita, o que no acontece no esquema do Two_Phase_locking padro. A diferena que uma transao pode ter delay at que uma operao seja comitada atravs do lock de certificao.
Desvantagem ?
Lock normal:
Read Read Write Sim No Write No No
Multiverso Two_phase locking:

Read Read Write Certify Sim Sim No Write Sim No No Certify No No No
Neste esquema, leituras podem proceder concorrentemente com operao de escrita, o que no acontece no esquema do Two_Phase_locking padro. A diferena que uma transao pode ter delay at que uma operao seja comitada atravs do lock de certificao.
Desvantagem: podem ocorrer deadlocks.
Validao (otimista)
Em todas as tcnicas discutidas at agora, um grau de checagem feita antes de uma operao no BD ser executada. Em tcnicas de controle de concorrncia por validao a checagem no feita enquanto a transao esta executando. Neste esquema, updates na transao no so aplicados diretamente nos itens do BD at a transao obter o seu fim. Durante a execuo da transao, todos os update so aplicados para uma cpia local. No momento em que a execuo de uma transao chega ao final, uma fase de validao realizada para checagem de violao da seriabilidade.
Validao (otimista)
Se a seriabilidade no violada, ento a transao comitada e a atualizao feita da copia local para o BD. Caso contrrio, a transao abortada e reiniciada. Trs fases so realizadas neste esquema: (1) Fase de leitura; (2) Fase de validao; (3) Fase de escrita;
Validao (otimista)
(1) Fase de leitura: Uma transao pode ler valores de itens de dados efetivados do BD. Entretanto, as atualizaes so aplicadas apenas s cpias locais (verses) dos itens de dados mantidos no espao de trabalho da transao. (2) Fase de validao: A verificao executada para garantir que a serializao no seja violada se as atualizaes da transao forem aplicadas ao BD. (3) Fase de escrita: Se a fase de validao bem sucedida, as atualizaes da transao so aplicadas ao BD, caso contrrio, as atualizaes so descartadas e a transao reiniciada.
Validao (otimista)
A idia fazer todas as verificaes de uma vez. Se h pouca interferncia entre as transaes, a maioria delas ser validada com sucesso. Entretanto, se h muita interferncia, vrias transaes em execuo tero seus resultados descartados, e devero ser reiniciadas mais tarde.
Granularidade de Itens de Dados
Todas as tcnicas de controle de concorrncia assumem que o BD formado por um conjunto de itens de dados.Um item do BD pode ser: - Um registro do banco de dados; - Um valor de campo de um registro de BD; - Um bloco de disco; - Um arquivo; - Um banco de dados inteiro.
Ex: Se o tamanho do item de dados um bloco de disco, uma transao T que precisa bloquear um registro B deve bloquear todo o bloco x de disco que contem B. Agora se uma outra transao S quer bloquear um registro C que esteja em x , ela vai ter que esperar. Quanto menor o tamanho do item de dados, maior ser o nmero de itens em um BD, consequentemente, o sistema ter um nmero maior de bloqueios ativos, ocasionando uma sobrecarga mais alta.
O tamanho dos itens de dados chamado de granularidade do item de dados: granularidade fina: tamanhos de item de dados pequenos; granularidade grossa: tamanho de item de dados maiores; Qual o melhor tratamento do item? Resposta: Depende dos tipos de transaes envolvidas. Se uma transao acessa um nmero pequeno de registros vantagem ter granularidade do item de dados em registro. Por outro lado, se uma transao acessa muitos registros em um mesmo arquivo, pode ser melhor usar a granularidade de bloco ou de arquivo.
Bloqueio de granularidade multipla
O nvel de granularidade pode ser diferente para os diferentes tipos de transaes. Na granularidade mltipla, um bloqueio pode ser requisitado em qualquer nvel.
BD F1 B11 B12 B1n B21 r211...r21k r111...r11j r121...r12j r1n1...r1nj F2 B22 B2m r221...r22k r2m1...r2mk
Considere que uma transao T1 queira atualizar todos os registros no arquivo F1, ento F1 bloqueado em modo exclusivo. Suponha que T2 queira apenas ler o registro r1nj de B1n de F1. Ento T2 exigiria um bloqueio compartilhado. Uma forma de verificao de bloqueio percorrer a rvore. Se um bloqueio detectado, a outra transao deve esperar.
BD F1 B11 B12 B1n B21 r211...r21k F2 B22 B2m
r111...r11j r121...r12j r1n1...r1nj
r221...r22k r2m1...r2mk
O que acontece se T2 tivesse solicitado a leitura de r1nj antes de T1?
Considere que uma transao T1 queira atualizar todos os registros no arquivo F1, ento F1 bloqueado em modo exclusivo. Suponha que T2 queira apenas ler o registro r1nj de B1n de F1. Ento T2 exigiria um bloqueio compartilhado. Uma forma de verificao de bloqueio percorrer a rvore. Se um bloqueio detectado, a outra transao deve esperar.
BD F1 B11 B12 B1n B21 r211...r21k F2 B22 B2m
r111...r11j r121...r12j r1n1...r1nj
r221...r22k r2m1...r2mk
O que acontece se T2 tivesse solicitado a leitura de r1nj antes de T1? Como o bloqueio de T2 compartilhado, T1 teria que verificar todos os ns (registros ou blocos) o que seria muito ineficiente.
Para tornar o bloqueio de granularidade mltipla prtico, so necessrios tipos de bloqueios adicionais, chamados bloqueios de inteno. A idia saber qual tipo de bloqueio ser solicitado (compartilhado ou exclusivo). Existem 3 tipos de bloqueios de inteno: 1 - Inteno- Compartilhado (IS); 2 - Inteno-Exclusiva(IX); 3 - Inteno-Compartilhada_Exclusiva(SIX).
1 - Inteno- Compartilhado (IS); Indica que bloqueio(s) compartilhado(s) ser(o) solicitado(s) em algum(ns) n(s) descendente(s); 2 - Inteno-Exclusiva(IX); Indica que bloqueio(s) exclusivo(s) ser(o) solicitado(s) em algum(ns) n(s) descendente(s); 3 - Inteno-Compartilhada_Exclusiva(SIX). Indica que o n corrente est bloqueado em modo compartilhado, mas bloqueio(s) exclusivo(s) ser(o) solicitado(s) em algum(ns) n(s) descendente(s);
Tabela de compatibilidade compartilhado e exclusivo. dos trs bloqueios de inteno,
O protocolo de bloqueio de granularidade mltipla consiste nas seguintes regras: 1 Compatibilidade de bloqueio baseada na tabela de compatibilidade dos trs bloqueios; 2 A raiz da rvore deve ser bloqueada primeiro, em qualquer modo. 3 Um n N pode ser bloqueado por uma transao T no modo S ou IS apenas se o n N pai j estiver bloqueado pela transao T no modo IS ou IX. 4 Um n N pode ser bloqueado por uma transao T no modo X, IX ou SIX apenas se o pai do n N j estiver bloqueado pela transaoT no modo IX ou SIX. 5 Uma transao T pode bloquear um n apenas se ela no tiver nenhum n desbloqueado. 6 Uma transao T pode desbloquear um n N apenas se nenhum dos ns filhos de N estiverem correntemente bloqueados por T.
Exemplo de plano de execuo serializvel possvel para as trs transaes:
a) T1 quer atualizar os registros de r111 at r211; b) T2 quer atualizar todos os registros no bloco B12 ; c) T3 quer ler o registro r11j e o F2 arquivo.
Insero , remoo e registros fantasmas
Quando um novo item de dado inserido no BD, ele no pode ser acessado at que o item seja criado e a operao de insero seja completada. A operao de remoo aplicada somente a um item existente. Para ordenao, o protocolo deve garantir que nenhuma transao atrasada tenha lido ou escrito um item antes de ele ser garantido pelo timestamp. O problema de registro fantasma pode ocorrer no momento de insero por exemplo, quando um dado aparece no BD, mas ele ainda no pode ser bloqueado. Uma tcnica chamada de bloqueio de predicado soluciona o problema dos registro fantasma, pois ela bloqueia o acesso a todos os registros que satisfazem a condio de um novo item de dado.

Tecnicas Controle Concorrencia

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tecnicas Controle Concorrencia

Загружено:

Авторское право:

Доступные форматы

Sistema de Gerenciamento de Banco de Dados Tcnicas de Controle de Concorrncia

Cincia da Computao UFG Catalo/GO Prof. Mrcio Antnio Duarte

gerenciador de bloqueio reinicia a transao)

lock manager wakes up the transaction);

de locks acionar a transao)

Exemplo de transaes que seguem o protocolo de 2 fases:

Mas no esto livres de deadlock!

Multiverso Two_phase locking:

Multiverso Two_phase locking:

Desvantagem: podem ocorrer deadlocks.

r111...r11j r121...r12j r1n1...r1nj

O que acontece se T2 tivesse solicitado a leitura de r1nj antes de T1?

r111...r11j r121...r12j r1n1...r1nj

Вам также может понравиться