read(x)

Propaganda
BANCO DE
DADOS
AULA - 07
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 1
PARTE - I
Gerenciamento de
Transações
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 2
Conceito de Transação
Uma transação é uma unidade de execução de programa
que acessa e, possivelmente, atualiza vários itens de dados.
Silberschatz
Transação provê mecanismos para descrever unidade
lógicas de processamento em um banco de dados.
Navathe
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 3
GERENCIAMENTO DE TRANSAÇÕES
• Em um sistema operacional de multiprogramação a execução de
um programa pode ser intercalada ou simultânea;
• A execução que acessa ou modifica o conteúdo de um BD é
chamada de transação;
• Podemos dizer que o conceito de transação é análogo ao de
processos em um sistema operacional;
• Uma transação é composta de várias operações;
• Todas as operações de uma transação devem ser completadas
com sucesso e seus efeitos gravados de forma permanente em
um BD;
• Uma transação pode ser interrompida, por algum tipo de falha,
antes da finalização de todas as operações. Neste caso o estado
do BD deverá ser recuperado;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 4
Operações Típicas de uma Transação
• Begin_Transaction: marca o início da execução de uma
transação;
• Read: Especifica uma operação de leitura a algum item do BD;
• Write: Especifica uma operação de escrita a algum item do BD;
• End_Transaction: Especifica que as operações terminaram e
marca o limite final da transação;
• Commit_Transaction: Sinaliza o final com sucesso de uma
transação de modo que qualquer atualização executada pela
transação possa ser efetivada no BD;
• Rollback: Sinaliza que a transação terminou sem sucesso e o
que foi executado deve ser desfeito;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 5
Operações Adicionais
• Undo: similar ao roollback, porém aplicada a uma única
transação;
• Redo: Especifica que certas operações devem ser refeitas para
garantir que todas as operações de uma transação efetivada
(commited) foram aplicadas com sucesso ao BD;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 6
Estados de uma Transação
READ/WRITE
BEGIN
TRANSACTION
END
TRANSACTION
COMMIT
PARCIALMENTE
EFETIVADA
ATIVA
ABORT
EFETIVADA
ABORT
FALHA
TERMINADA
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 7
Log do Sistema
• Utilizado para permitir recuperação de falhas de transações.
Também chamado de Journal;
• Registra todas as operações que afetam valores de itens do BD;
• É guardado em disco;
• Deve sofrer backup periodicamente;
• Tipo de entrada no Log:
[start_transaction, T]
[write_item, T, X, old_value, new_value]
[read_item, T, X]
[commit, T]
[abort, T]
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 8
Pontos de Controle
• Commit Point
Quando todas as operações que acessam o BD foram
executadas com sucesso e efeito destas operações no BD já
foram gravadas no Log;
O commit point está associado a uma transação específica.
• Checkpoint
É escrito no Log periodicamente quando o sistema grava no
disco todas as operações Write de transações efetivadas.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 9
Checkpoint
• O gerenciamento de recuperação do SGBD deve decidir em que
tipo de intervalo deve ocorrer o checkpoint:
Em unidade de tempo;
Em número de transações efetivadas após o último checkpoint;
• Ações de um checkpoint:
Suspender temporariamente a execução de transações;
Forçar a escrita de todas as operações de modificação das
transações efetivadas do buffer para o disco;
Escrever um registro de checkpoint e forçar a escrita do log no
disco;
retornar à execução de transações.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 10
Propriedades Desejáveis de uma Transação
• Atomicidade – Unidade atômica de processamento;
• Consistência – A correta execução de uma transação
deve levar o BD de um estado consistente para outro
estado consistente;
• Isolamento – As atualizações não devem ser tornadas
visíveis para outras transações até o commit;
• Durabilidade – Sempre que o BD for modificado e estas
mudanças forem efetivadas, não poderão ser perdidas por
alguma falha posterior;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 11
ESCALONAMENTO DE TRANSAÇÕES
• É também denominado de história de transações;
• Diz respeito à ordem de execução das operações de várias
transações executadas concorrentemente;
• Um escalonamento S de n transações T1, T2, ..., Tn, é um
ordenamento de operações dessas transações, sujeito à
restrição de que para cada transação Ti em S, as
operações de Ti em S devem aparecer na mesma ordem
que ocorrem em Ti;
Operações conflitantes
São operações que pertencem a diferentes transações,
acessam o mesmo item e pelo menos uma das duas
operações é um write_item;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 12
Escalonamento Recuperável
• É o escalonamento onde nenhuma transação T em S é
efetivada até que todas as transações T’, que escrevam
um item a ser lido por T, tenham sido efetivadas;
Rollback em cascata
• Uma transação não efetivada tem que ser rolled back
porque lê um item de uma transação que falhou;
• Toda transação que no escalonamento que apenas lêem
itens por transações efetivadas evitam rollback em
cascata. Esta estratégia á mais restritiva, porém pode ser
eficiente quando falhas são constantes;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 13
Escalonamento Estrito
• Ocorre quando nenhuma transação pode ler ou escrever
itens que a última transação que o escreveu não tenha
sido efetivada ou abortada.
Escalonamento sem Intercalação
• Ocorre quando todas as operações de uma transação T1
são seguidas por toda as operações de T2, ou vice-versa;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 14
TEORIA DA SERIALIZABILIDADE
• Tenta determinar quais escalonamentos são corretos e
quais não são;
• Engloba a aplicação de técnicas que permita apenas
escalonamento corretos.
Escalonamento Serial
• Ocorre quando as operações de cada transação são
executadas consecutivamente, sem operações intercaladas
com a de outras transação;
• Este tipo de transação não gera conflito.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 15
Escalonamento Não-serial
• As operações de uma transação são executadas
intercaladas com as operações de outras transações;
Escalonamento Serializável
• É equivalente a algum escalonamento serial com as
mesmas n transações;
• Escalonamentos com resultados equivalentes produzem o
mesmo resultado final da BD
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 16
TESTE DE CONFLITO DE SERIALIZABILIDADE
• Para testar se há conflito de serializabilidade em um
determinado escalonamento, utiliza-se uma técnica
baseada em um grafo de precedência, construído a partir
da seqüência de operações do escalonamento;
• Grafo de precedência é um grafo dirigido G=(N,E) que
consiste de um conjunto de nós N={T1,T2,...,Tn} e um
conjunto de lados dirigidos E={e1,e2,...,em}
• Algoritmo :
1. Para cada transação participando de um escalonamento
S, criar um nó rotulado de Ti no grafo de precedência;
2. Para cada caso em S onde uma transação Tj executa
um read_item(x) após um write_item(x) executada por
outra transação Ti, crie um lado (Ti -> Tj) no grafo de
precedência;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 17
• Algoritmo :
3. Para cada caso em S onde uma transação Tj executa
um write_item(x) após um read_item(x) executada por
outra transação Ti, crie um lado (Ti -> Tj) no grafo de
precedência;
4. Para cada caso em S onde uma transação Tj executa
um write_item(x) após um write_item(x) executada por
outra transação Ti, crie um lado (Ti -> Tj) no grafo de
precedência;
5. Um escalonamento é serializável se e somente se o
grafo de precedência não tem ciclos.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 18
Exemplos de Escalonamentos
T1
T2
read(x)
x = x + 5;
write(x)
read(y)
y = y + x;
write(y)
read(x)
x = x * 3;
write(x)
T
1
Weyler N M Lopes ©
T
2
Especialização em Banco de Dados
SERIALIZÁVEL
Página 19
T1
T2
read(x)
x = x * 3;
write(x)
read(x)
x = x + 5;
write(x)
read(y)
y = y + x;
write(y)
T
1
Weyler N M Lopes ©
T
2
Especialização em Banco de Dados
SERIALIZÁVEL
Página 20
T1
T2
read(x)
x = x + 5;
read(x)
x = x * 3;
write(x)
read(y)
write(x)
y = y + x;
write(y)
T
1
Weyler N M Lopes ©
T
2
NÃO SERIALIZÁVEL
Especialização em Banco de Dados
Página 21
EXERCÍCIOS
1) Todos os termos relacionados a seguir estão associados a gerenciamento de
transações. O que significa cada um deles?
Log;
Rollback;
Commit_Transaction;
Checkpoint;
ACID.
2)
Baseado no seguinte esquema de execução de transações, responda os itens
subseqüentes: (2,0)
T1
T2
T3
read(y)
read(x)
x = x + 5;
read(x)
x = x * 3;
write(x)
read(y)
write(x)
y = y + x;
write(y)
a)
b)
c)
d)
O que você entende por escalonamento serializável?
Construa um grafo de precedência para o escalonamento descrito acima.
Este esquema representa um escalonamento serializável? Justifique.
Elabore um escalonamento serializável para o esquema.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 22
NÍVEIS DE CONSISTÊNCIA
Serializável — default
Read repetitivo — somente registros que sofreram
efetivação podem ser lidos, leituras repetidas do mesmo
registro devem retornar o mesmo valor.
Read com efetivação — somente registros que sofreram
efetivação podem ser lidos, mas leituras sucessivas de
registro podem retornar valores diferentes (mas que
sofreram efetivação).
Read sem efetivação — até mesmo registros que não
sofreram efetivação podem ser lidos.
Graus de consistência mais baixos são úteis para reunir
informações aproximadas sobre o banco de dados, p. ex.,
dados estatísticos para o otimizador de consultas.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 23
CONCORRÊNCIA E SERIALIZABILIDADE
•Testar a serializabilidade de um escalonamento após ele
ter sido executado é um pouco tardio!
•Meta – desenvolver protocolos de controle de
concorrência que assegurem a serializabilidade . Eles
geralmente não irão examinar o grafo de precedência
assim que ele tiver sido criado; em vez disso, o protocolo
irá impor uma disciplina que evite escalonamentos nãoserializáveis.
•Testes de serializabilidade ajudam a compreender
porque um protocolo de controle de concorrência está
correto.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 24
PARTE - II
Controle de Concorrência
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 25
DEFINIÇÃO
Concorrência é a propriedade de uma transação
poder ser executada em paralelo com outras
transações.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 26
Justificativa de uso
Com a execução de várias transações ao mesmo tempo , o
processador pode ser compartilhado entre estas transações,
melhorando a eficiência global do computador, uma vez que
uma quantidade maior de tarefas é executada em paralelo.
Justificativa de Controle
É necessário que o sistema monitore a interação entre
transações concorrentes, de modo a evitar que a
consistência do BD seja destruída.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 27
Arquitetura do SGBD para o Controle
TRANSAÇÕES
GERENCIADOR DE
TRANSAÇÕES
ESCALONADOR
GERENCIADOR DE
DADOS
GERENCIADOR DE
RECUPERAÇÃO
GERENCIADOR
CACHE
Weyler N M Lopes ©
Especialização em Banco de Dados
BD
Página 28
TÉCNICAS DE BLOQUEIO
LOCK
Variável associada a um item de dados no BD que
representa o status deste item com relação a possíveis
operações a serem aplicadas sobre ele.
Lock Binário
Assume dois valores que representam dois estados:
locked(1) ou unlocked(0).
Um lock distinto é associado a cada item do BD –
referenciado como lock(x) para o item x
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 29
Lock Binário
(continuação)
Operações incluídas nas transações:
lock_item
unlock_item
Estas operações são implementadas como operações
indivisíveis;
Um gerenciador é mantido pelo SGBD para gerenciar e
controlar o acesso a locks;
Para cada lock efetuado é mantido um registro da
forma:<nome-item,LOCK>;
Estes registros são mantidos em uma tabela de lock;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 30
Lock Binário
(continuação)
Regras de gerenciamento:
 Uma transação T tem que executar uma operação
lock_item(x) antes de qualquer read_item ou write_item
executado por T;
 Uma transação T tem que executar a operação
unlock_item(x) após todo read/write completados em T;
Uma transação não pode executar uma operação
lock_item(x) se já tem um lock sobre x;
Uma operação T não pode executar um unlock_item(x) a
menos que tenha um lock sobre x;
Apenas uma transação pode ter um lock sobre um dado
item;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 31
Lock de Modo Múltiplo
Neste tipo de lock, há três operações indivisíveis:
 read_lock(x) – lock compartilhado;
 write_lock(x) – lock exlusivo;
 unlock(x).
O registro de lock, neste caso, assume o seguinte formato:
<nome-item, LOCK, numero-leituras>
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 32
Lock de Modo Múltiplo
(continuação)
Regras de gerenciamento:
 Uma transação T tem que executar uma operação
read_lock(x) ou write_lock(x) antes de qualquer
read_item(x) executado por T;
 Uma transação T tem que executar uma operação
write_lock(x) antes de qualquer write_item(x) em T;
 Uma transação T tem que executar uma operação
unlock(x) após todas as operações read_item(x) ou
write_item(x) completadas em T;
Uma transação T não executará um read_lock(x) se já tem
um lock compartilhado (read_lock) ou um lock_exclusivo
(write_lock) em x;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 33
Lock de Modo Múltiplo
(continuação)
Incremento de LOCK:
 Uma transação T após ter um read_lock(x) e sendo a
única que detém x, pode posteriormente executar um
write_lock(x);
Decremento de LOCK:
Após ter um lock exclusivo sobre um item x, uma transação
T pode decrementar o lock, executando um read_lock(x).
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 34
TÉCNICAS DE BLOQUEIO
(continuação)
Locks binários ou múltiplos não garantem a
serializabilidade de escalonamentos nos quais
transações participam. É necessário um protocolo
adicional que contempla o posicionamento dos
locks e unlocks em cada transação;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 35
Bloqueios Exclusivos
Se uma transação T contiver um bloqueio exclusivo em
algum item, então nenhuma transação distinta T’ pode fazer
bloqueio daquele objeto até que T libere seu bloqueio;
Bloqueios exclusivos seguem o seguinte protocolo:
 Qualquer transação que pretenda atualizar um registro R,
primeiro terá que acessar aquele registro e bloqueá-lo
exclusivamente. Se o bloqueio não puder ser realizado, a
transação entra em estado de espera e apenas continuará a
ser executada quando o registro se tornar disponível e o
bloqueio puder ser concedido;
O sistema terá que garantir que uma transação forçada a
esperar por causa deste protocolo, eventualmente sairá
deste estado de espera. Assim, não sofrerá livelock.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 36
Bloqueios Exclusivos
(continuação)
 Par evitar a possibilidade de perda de atualizações,
nenhuma transação poderá ter acesso aos dados de uma
transação não efetuada;
Bloqueios Compartilhados
Se uma transação T mantiver um bloqueio compartilhado
em algum item, então uma transação T’ distinta também
pode fazer um bloqueio compartilhado sobre aquele item.
Porém, nenhuma transação T’ distinta pode fazer um
bloqueio exclusivo sobre aquele item até que todos os
bloqueios compartilhados sobre o item tenham sido
liberados;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 37
Bloqueios de Duas Fases
Ocorre quando todas as transações obedecem às seguintes
regras:
1. Antes de operar sobre qualquer item, primeiro a
transação adquire bloqueio sobre este item;
2. Após liberar o bloqueio, a transação não adquire mais
bloqueios;
Todas as transações intercaladas destas transações são
serializáveis;
Fases do bloqueio:
Crescente: quando bloqueios são feitos;
Encolhimento: quando bloqueios são liberados.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 38
Bloqueios de Duas Fases
(continuação)
Se o decréscimo do lock for permitido, ele tem que ser feito
na fase de encolhimento.
Uma transação tem que manter um lock sobre x mesmo
que não precise dele, se tiver que exercer um lock sobre
outro item y. Este é um fato que limita o acesso
concorrente;
Variações do protocolo:
• Básico: protocolo apresentado anteriormente;
• Conservador ou Estático: bloqueia todos os itens que
irão acessar, antes de iniciar a execução da transação;
• Estrito: Não libera os locks até o commit ou abort.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 39
Deadlock
É uma situação em que uma ou mais transações estão em
estado simultâneo de espera, cada uma aguardando que a
outra libere um bloqueio para poder prosseguir.
Principais métodos para solucionar o impasse:
 Protocolos de prevenção de deadlock:
Conservador: Se algum dos itens não pode ser bloqueado,
nenhum será bloqueado;
Ordenado: Tentar por uma ordenação em todos os itens.
Os locks só podem ocorrer segundo esta ordem;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 40
Deadlock
(continuação)
 Técnicas baseada em timestamp:
Identificador único é assinalado em cada transação;
Estes identificadores são ordenados segundo a ordem que
as transações começam;
Tem a não utilização de bloqueios como principal vantagem,
o que impossibilita a existência de dealocks;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 41
Deadlock

(continuação)
Técnicas baseada em timestamp:
(continuação)
O protocolo associado a esta técnica é o seguinte:

Quando uma transação solicita um bloqueio de
registro que já está bloqueado por outra transação,
então um dos dois procedimentos é seguido:
1)
wait-die: se a transação que solicitou o bloqueio é a
mais antiga, pode aguardar. Se for a mais nova, sofre
rollback e começa mais tarde com o mesmo
timestamp;
2)
Wound-wait: Se a transação for a mais nova, pode
aguardar. Se for a mais antiga, interrompe a nova que
sofre rollback e mais tarde recomeça com o mesmo
timestamp.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 42
Deadlock

(continuação)
Técnicas baseada detecção e recuperação:
É baseada na verificação da existência de deadlock. Possui
basicamente duas políticas de verificação:
1)
Identifica imediatamente sempre a existência de uma
solicitação de bloqueio que cause espera. Tal política,
apesar de resolver imediatamente o impasse, acarreta
em um overhead;
2)
Toma por base um intervalo de tempo para verificar a
existência de deadlock. Reduz o overhead, porém,
deadlocks podem ser detectados de forma tardia.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 43
Deadlock
(continuação)
Condições ideais para evitar deadlocks:
1) Pequena interferência entre as transações;
2) Transações curtas;
3) Locks de poucos itens;
4) Carga de transação leve.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 44
Deadlock
(continuação)
A quebra de deadlock consiste na escolha de uma das
transações para forçá-la a um rollback. As opções são:
1) A que foi iniciada mais cedo;
2) A que tiver realizado o menor número de bloqueios;
3) A que tiver feito menor número de atualizações;
Políticas baseadas em que de deadlock agem sobre
situações opostas às pretendidas pelas políticas de
prevenção.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 45
Livelock
Ocorre quando uma determinada transação não pode
prosseguir por um período indefinido de tempo, enquanto
outras transações continuam normalmente;
Livelocks têm sua origem em esquemas injustos de espera;
Podem ser evitados através das seguintes políticas:
 First-come-first-serve
 Incremento de prioridade com o tempo
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 46
Starvation
Problema similar ao livelock. Ocorre quando a mesma
transação é “vítima” várias vezes para ser abortada, e por
conseguinte, nunca encerrando a sua execução;
Os protocolos wait-die e wound-wait, apresentados
anteriormente, evitam este tipo de problema.
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 47
Conclusão
O ambiente de um BD se difere de outros ambientes no que
concerne a problemas de bloqueios devido a vários fatores.
Dentre eles, podemos destacar:
Conjunto de objetos bloqueáveis não é só muito grande,
como também mudam de forma rápida;
Objetos bloqueáveis são tipicamente endereçáveis pelo
conteúdo;
Escopo preciso do bloqueio para determinada transação,
normalmente é determinado com muito rapidez ;
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 48
EXERCÍCIO
Há algumas outras técnicas de controle de concorrência
que não foram apresentadas com detalhes. Escolha uma
destas técnicas e escreva um pequeno artigo descrevendo
suas características.
Sugestão: Dentre as técnicas, observe as não orientadas a
bloqueio (técnicas baseadas em timestamp)
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 49
PARTE - III
Controle de Acesso
(estudo prático em PostgreSQL)
Weyler N M Lopes ©
Especialização em Banco de Dados
Página 50
Download