A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Sistemas de Gerenciamento de Bancos de Dados José Maria Monteiro Universidade Federal do Ceará Departamento de Computação

Apresentações semelhantes


Apresentação em tema: "Sistemas de Gerenciamento de Bancos de Dados José Maria Monteiro Universidade Federal do Ceará Departamento de Computação"— Transcrição da apresentação:

1 Sistemas de Gerenciamento de Bancos de Dados José Maria Monteiro Universidade Federal do Ceará Departamento de Computação

2 © José Maria Monteiro. 2 Sumário Processamento de Transações Controle de Concorrência Recuperação (Reconstrução após Falha) Armazenamento de Dados Processamento de Consulta Otimização de Consulta Projeto Físico e Tuning de Banco de Dados Segurança 

3 © José Maria Monteiro. 3 Processamento de Transações

4 © José Maria Monteiro. 4 Processamento de Transações Introdução ao Processamento de Transações O Conceito de Transação Propriedades das Transações Execução Correta de Transações Concorrentes  O Conceito de Schedule  Schedules Serializáveis  O Teorema da Serializabilidade  Confiabilidade de Schedules

5 © José Maria Monteiro. 5 Introdução ao Processamento de Transações Banco de Dados  Coleção de objetos que representam entidades do mundo real  Cada objeto do BD tem um nome e um valor Ex: Conta A com valor de Estado do BD  Conjunto de valores de todos os objetos do BD em um dado instante de tempo

6 © José Maria Monteiro. 6 Introdução ao Processamento de Transações Estado do BD  O estado de um banco de dados representa uma visão instantânea do mundo real  Reflete apenas seus aspectos estáticos  As mudanças que ocorrem no mundo real devem ser refletidas no BD Transição de Estados  Representa o saldo de um estado para outro

7 © José Maria Monteiro. 7 Introdução ao Processamento de Transações Transição de Estados  São realizadas pelos programas aplicativos Executam operações de leitura e escrita sobre os objetos do BD Restrições de Consistência  O mundo real impõe certas restrições sobre o BD Ex: Uma conta bancária não pode ter saldo negativo  Logo, os bancos de dados devem capturar estas restrições, chamadas restrições de consistência

8 © José Maria Monteiro. 8 Introdução ao Processamento de Transações Consistência Se todos os objetos de um banco de dados, em um dado instante, satisfazem todas as restrições de consistência dizemos que o estado do banco de dados é consistente.

9 © José Maria Monteiro. 9 Introdução ao Processamento de Transações Execução Concorrente  As aplicações executam em modo concorrente  Através do entrelaçamento das operações de diferentes programas  Pode levar a mudanças inconsistentes P1P2__ Read(A) Write(A, A- 100) Write (A, A-200) Tempo

10 © José Maria Monteiro. 10 Introdução ao Processamento de Transações A execução concorrente de programas aplicativos deve ser monitorada e controlada. Esta funcionalidade é chamada controle de concorrência.

11 © José Maria Monteiro. 11 Introdução ao Processamento de Transações Modelo Transacional Clássico Nem todas as operações de um programa são relevantes, somente as operações sobre o banco de dados necessitam ser consideradas.

12 © José Maria Monteiro. 12 Introdução ao Processamento de Transações Modelo Transacional Clássico Uma transação é uma abstração que representa uma seqüência de operações sobre o banco de dados (leitura e escrita) resultante da execução de um programa aplicativo.

13 © José Maria Monteiro. 13 Introdução ao Processamento de Transações Modelo Transacional Clássico  A execução concorrente de um conjunto de transações é realizada através do entrelaçamento das operações que compõem as várias transações  Alguns entrelaçamentos podem produzir estados inconsistentes  Quando uma execução concorrente de um conjunto de transações esta corretamente entrelaçada ??? Ou seja, resulta em estados consistentes ???

14 © José Maria Monteiro. 14 Introdução ao Processamento de Transações Modelo Transacional Clássico Um estado consistente do banco de dados representa uma visão coerente do mundo real.

15 © José Maria Monteiro. 15 Introdução ao Processamento de Transações Modelo Transacional Clássico Critério de Corretude: Uma execução de transações concorrentes é correta se ela produz um estado consistente do banco de dados.

16 © José Maria Monteiro. 16 Introdução ao Processamento de Transações Modelo Transacional Clássico  A primeira vista este critério de corretude parece bastante razoável  Infelizmente Nas aplicações reais nem todas as restrições de consistência são conhecidas Torna inviável a identificação de um estado consistente

17 © José Maria Monteiro. 17 Introdução ao Processamento de Transações Modelo Transacional Clássico Em geral, a única informação disponível sobre as restrições de consistência é que uma aplicação (transação) preserva a consistência do banco de dados.

18 © José Maria Monteiro. 18 Introdução ao Processamento de Transações Modelo Transacional Clássico Se o estado do BD estava consistente antes do início da transação ele será consistente após o término da transação. Estados intermediários podem estar incoerentes.

19 © José Maria Monteiro. 19 Introdução ao Processamento de Transações Modelo Transacional Clássico A execução de uma transação é correta, ou seja, preserva a consistência do BD, se a transação é executada por completo e de forma isolada das demais transações.

20 © José Maria Monteiro. 20 Introdução ao Processamento de Transações Modelo Transacional Clássico Desde que a execução de uma transação seja correta, é fácil mostrar, usando indução sobre o número de transações, que qualquer execução serial de um conjunto de transações é correta.

21 © José Maria Monteiro. 21 Introdução ao Processamento de Transações Modelo Transacional Clássico Serializabilidade: Se uma execução concorrente de um conjunto de transações é equivalente à alguma execução serial das mesmas transações, então ela também é correta.

22 © José Maria Monteiro. 22 Introdução ao Processamento de Transações Modelo Transacional Clássico  Serializabilidade Proporciona a ilusão que a execução concorrente de múltiplas transações acontece de forma serial Ilusão de que a execução de uma transação consiste em uma ação atômica Uma transação é considerada uma unidade de execução atômica

23 © José Maria Monteiro. 23 Definição Uma transação é uma abstração que representa uma seqüência de operações sobre o banco de dados (leitura e escrita) resultante da execução de um programa aplicativo. O Conceito de Transação

24 © José Maria Monteiro. 24 O Conceito de Transação Transações  Transações são usadas para representar as operações sobre o banco de dados executadas pelas aplicações  Indicam a ordem na qual as operações sobre o banco de dados devem ser executadas

25 © José Maria Monteiro. 25 O Conceito de Transação Operações  r i (x) A transação T i lê o item de dado chamado x para uma variável de programa  w i (x) Escreve o valor de uma variável de programa no item de dado x r 1 (x); x:=x-n; w 1 (x); r 1 (y); y:=y+n; w 1 (y); r 2 (x); x:=x+m; w 2 (x); T1T1 T2T2

26 © José Maria Monteiro. 26 O Conceito de Transação Ações Transacionais  begin_transaction: início da execução de uma transação  read ou write: modificam os dados da base  end_transaction: limite final da execução de uma transação  commit: final da transação com sucesso. Torna permanente as modificações nos dados  rollback: efeitos da transação sobre os dados devem ser desfeitos

27 © José Maria Monteiro. 27 O Conceito de Transação Diagrama de Estados Ativa begin transaction Parcialmente Validada end transaction Validada commit FinalizadaFalha rollback read, write

28 © José Maria Monteiro. 28 O Conceito de Transação Notação  OP(T i ) Representa o conjunto de todas as operações executadas pela transação T i  Commit (c i ) Indica que a transação T i encontra-se no estado parcialmente executado e que deseja passar para o estado executado (commited)  Abort (a i ) Indica que a transação T i deseja entrar no estado de falha (aborted)

29 © José Maria Monteiro. 29 O Conceito de Transação Notação  Uma transação T i deverá conter após todas as operações de leitura e escrita uma operação commit (c i ) ou abort (a i ), mas não ambas

30 © José Maria Monteiro. 30 O Conceito de Transação Definição  Mais formalmente podemos definir uma transação T i como uma ordem com relação de ordem < i onde: (1) OP(T i )  {r i (x), w i (x) | x é um item de dado}  {a i, c i } (2) a i  T i se e somente se c i  T i (3) Seja t c i ou a i, para qualquer operação p  T i, p < i t e (4) Se r i (x), w i (x)  T i, então r i (x) < i w i (x) ou w i (x) < i r i (x) A relação de ordem < i representa a precedência entre duas operações de uma transação T i.

31 © José Maria Monteiro. 31 Objetivo do Controle de Concorrência Transações Concorrentes Maximizar a concorrência entre as transações ao mesmo tempo em que garante a consistência do banco de dados.

32 © José Maria Monteiro. 32 Execução de Transações Concorrentes Transações Concorrentes A execução concorrente de um conjunto de transações é realizada através do entrelaçamento das operações que compõem as várias transações.

33 © José Maria Monteiro. 33 História ou Schedule  Uma história ou schedule indica a ordem na qual as operações de um conjunto de transações são executadas com relação uma com as outras, ou seja, ela representa uma execução concorrente  A ordem das operações em uma transação deve ser preservada Se p i precede q i, na transação T i (isto é, p i < i q i ), então a execução de p i deve acontecer antes de q i em qualquer schedule contendo T i.  A execução de um schedule representa o mapeamento de um estado do banco de dados para outro Transações Concorrentes

34 © José Maria Monteiro. 34 Notação  OP(S) Representa o conjunto das operações executadas no schedule S  p < s q Indica que a operação p foi executada antes da operação q no schedule S Ex: r i (x) < s r j (y) representa o fato de que a operação r i (x)  T i precede r j (y)  T j, no schedule S, onde S é executado sobre um conjunto de transações T e T i, T j  T Transações Concorrentes

35 © José Maria Monteiro. 35 Notação  Seja S um schedule sobre o conjunto G  L de transações, onde G e L são conjutos disjuntos de transações. A projeção do schedule S sobre o conjunto G é um schedule S’ para o qual as seguintes condições devem ser satisfeitas: (1) S’ contem somente as operações das transações pertencentes ao conjunto G. (2)  p,q  OP(S’)  p, q  OP(S) (3)  p,q  OP(S’), p < s’ q  p < s q Transações Concorrentes

36 © José Maria Monteiro. 36 Schedule Serial  Um schedule S é serial se, para cada par de transações T i, T j  S, todas as operações de T i aparecem antes de todas as operações de T j ou vice-versa.  Assim podemos denotar um schedule serial sobre T 1, T 2, T 3,..., T n como T i1, T i2, T i3,...., T in onde i 1, i 2,...., i n é uma permutação de 1, 2,..., n. Transações Concorrentes

37 © José Maria Monteiro. 37 Schedule Serial  Não permite entrelaçamento entre as operações das transações  Processamento ineficiente: perda desnecessária de tempo de CPU  Premissa: A execução de uma transação simples, de forma completa e isolada das demais transações, preserva a consistência do banco de dados Transações Concorrentes

38 © José Maria Monteiro. 38 Transações Concorrentes Schedule Serial  É fácil mostrar usando indução, que qualquer execução serial de (schedule serial) de um conjunto de transações é correta, ou seja, preserva a consistência do banco de dados  Se um schedule tem n transações então teremos (n)! schedules seriais corretos

39 © José Maria Monteiro. 39 Transações Concorrentes Schedule Não-Serial  Na prática, as transações são executadas em modo concorrente  Entrelaçamento entre as operações das transações  Aumenta o throughput: maior número de transações por espaço de tempo  Interferência entre as transações pode gerar inconsistências no banco de dados  O número de schedules não-seriais é enorme

40 © José Maria Monteiro. 40 Transações Concorrentes Exemplos de Schedules T1T1 T2T2 read(x) x:=x-n write(x) read(y) y:=y+n write(y) read(x) x:=x+n write(x) Schedule Serial T1T1 T2T2 read(x) x:=x-n read(x) x:=x+n Schedule Não-Serial Incorreto write(x) read(y) write(x) y:=y+n write(y) T1T1 T2T2 read(x) x:=x-n write(x) read(x) x:=x+n write(x) Schedule Não-Serial Correto read(y) y:=y+n write(y)

41 © José Maria Monteiro. 41 Transações Concorrentes Critério de Corretude  Se uma execução concorrente de um conjunto de transações T é equivalente a alguma execução serial de T então ela também é correta Um schedule S é serializável se ele for equivalente a algum schedule serial S s. Logo, um schedule serializável é correto.

42 © José Maria Monteiro. 42 Transações Concorrentes Critério de Corretude  Desta forma, reduzimos o problema de identificar schedules corretos ao problema de definir equivalência entre schedules  Existem três noções de equivalência entre schedules Equivalência por estado final Equivalência por visão Equivalência por conflito

43 © José Maria Monteiro. 43 Transações Concorrentes Equivalência por Estado Final  Dois schedules executados sobre o mesmo conjunto de transações T são ditos equivalentes por estado final se: (i) possuem as mesmas operações pertencentes às transações em T, e (ii) produzem o mesmo estado do banco de dados, caso sejam executadas a partir do mesmo estado inicial

44 © José Maria Monteiro. 44 Transações Concorrentes Equivalência por Estado Final  Classe mais genérica de equivalência entre schedules  Idéia:  Identificar schedules que realizam a mesma transição de estados quando são executados a partir do mesmo estado inicial  Dois schedules equivalentes por estado final produzem o mesmo efeito sobre o banco de dados

45 © José Maria Monteiro. 45 Transações Concorrentes Equivalência por Visão  Dois schedules S e S’ executados sobre o mesmo conjunto de transações T são ditos equivalentes por visão se: (i) envolvem as mesmas operações pertencentes às transações em T, (ii) para toda operação r i (x) de uma transação T i  T, o valor lido por r i deve ser o mesmo nos dois schedules, e (iii) se w i (x) é a última operação sobre um objeto x em S, então w i (x) é também a última operação de escrita sobre x em S

46 © José Maria Monteiro. 46 Transações Concorrentes Equivalência por Visão  As operações de leitura em schedules equivalentes por visão têm a mesma visão do BD  Como o resultado de uma operação de escrita é uma função de todos os valores lidos anteriormente pela transação, a condição (iii) garante que a última operação de escrita nos dois schedules produzem o mesmo efeito sobre o banco de dados  Schedules equivalentes por visão produzem o mesmo efeito sobre o banco de dados

47 © José Maria Monteiro. 47 Transações Concorrentes Equivalência por Visão  Observe a condição (ii):  representa uma restrição sobre a classe de schedules equivalentes por estado final  requer que schedules equivalentes por estado final tenham a mesma visão do banco de dados  A equivalência por visão é um caso especial de equivalência por estado final  A classe de schedules equivalentes por visão é um subconjunto da classe de schedules equivalentes por estado final

48 © José Maria Monteiro. 48 Transações Concorrentes Equivalência por Visão  Dois schedules equivalentes por visão são também equivalentes por estado final

49 © José Maria Monteiro. 49 Transações Concorrentes Equivalência por Conflito Duas operações de diferentes transações conflitam (ou estão em conflito) se e somente se elas acessam o mesmo objeto do banco de dados e pelo menos uma delas é uma operação de escrita.

50 © José Maria Monteiro. 50 Transações Concorrentes Equivalência por Conflito  De acordo com a definição de conflito:  uma operação r i (x) sempre conflita com w j (x) e  w i (x) conflita com r j (x) e w j (x), onde i  j.  w i (x) não conflita com w j (y)  r i (x) não conflita com r j (x)

51 © José Maria Monteiro. 51 Transações Concorrentes Equivalência por Conflito  Dois schedules S e S’ executados sobre o mesmo conjunto de transações T são ditos equivalentes por conflito se: (i) envolvem as mesmas operações pertencentes às transações em T, (ii) para toda operação p i (x)  OP(T i ) que conflita com uma operação q j  OP(T j ), com i  j, se p i < s q j, então p i < s’ q j

52 © José Maria Monteiro. 52 Transações Concorrentes Equivalência por Conflito  Dois schedules são equivalentes por conflito se as operações que conflitam estão na mesma ordem Podemos distinguir três conceitos de schedules corretos:  Serializabilidade por estado final (FSR)  Serializabilidade por visão (VSR)  Serializabilidade por conflito (CSR)

53 © José Maria Monteiro. 53 Transações Concorrentes Três conceitos de schedules corretos:  Serializabilidade por estado final (FSR) Um schedule S é serializável por estado final se ele é equivalente por estado final a algum schedule serial.  Serializabilidade por visão (VSR) Um schedule S é serializável por visão se ele é equivalente por visão a algum schedule serial.  Serializabilidade por conflito (CSR) Um schedule S é serializável por conflito se ele é equivalente por conflito a algum schedule serial.

54 © José Maria Monteiro. 54 Transações Concorrentes Três conceitos de schedules corretos:  Cada noção de corretude representa um grau de concorrência diferente Pode permitir um maior ou menor entrelaçamento entre as operações das diferentes transações Quanto maior for entrelaçamento permitido menos restritivo será o critério de corretude FSR  VSR  CSR Um schedule S é serializável por conflito se ele é equivalente por conflito a algum schedule serial.

55 © José Maria Monteiro. 55 Transações Concorrentes Três conceitos de schedules corretos:  Serializabilidade por estado final Baseia-se nos conceitos de estado inicial e final do banco, os quais não são capturados pelo conceito de schedule  Serializabilidade por visão Verificar se um schedule é serializável por visão é um problema NP-Completo  Serializabilidade por conflito Podemos verificar se um schedule é serializável por conflito em tempo polinomial Quase todos os trabalhos práticos implementam a serializabilidade por conflito como critério de corretude

56 © José Maria Monteiro. 56 Transações Concorrentes Serializabilidade por Conflito  Verificando se um schedule S é serializável por conflito A idéia básica consiste em verificar se um grafo direcionado, chamado grafo de serialização, possui ou não ciclos

57 © José Maria Monteiro. 57 Transações Concorrentes Grafo de Serialização  Seja S um schedule sobre um conjunto de transações T = {T 1, T 2,..., T n }.  O grafo de serializaçãoo para S, representado por GS(S), é definido como: O grafo direcionado GS(S) = (N,A) Cada nó em N representa uma transação em T O conjunto A contém as arestas na forma T i  T j, se e somente se T i, T j  N e existem duas operações p  OP(T i ) e q  OP(T j ), onde p conflita com q e p < S q

58 © José Maria Monteiro. 58 Transações Concorrentes Serializabilidade por Conflito  O conceito de grafo de serialização proporciona um método eficiente para identificar schedules CSR  Teorema Um schedule S é serializável por conflito se e somente se o grafo de serialização para S é acíclico.

59 © José Maria Monteiro. 59 Transações Concorrentes Propriedade “prefix-closed”  Temos analisado a corretude de schedules completos Os quais são representados através da execução completa das transações Ambientes dinâmicos  considerar schedules incompletos  “prefix-closed” Se um schedule S é correto então qualquer prefixo de S também é correto Nem todo critério de corretude é “prefix-closed”  Teorema: A serializabilidade por conflito é “prefix-closed”

60 © José Maria Monteiro. 60 Transações Concorrentes Protocolos para Controle de Concorrência  Potocolos Pessimistas (Controle Contínuo) Verificação antes de executar operação sobre a base A verificação contínua penaliza o desempenho das transações  Protocolos Otimistas Não há qualquer verificação durante a execução das transações Serializabilidade verificada em um único instante  No momento da validação Pouca interferência -> Ótimo desempenho Muita interferência -> Descartes demais

61 © José Maria Monteiro. 61 Transações Concorrentes Protocolos para Controle de Concorrência  Protocolos Otimistas Fase de Leitura  As transações fazem acesso à base mas atualizam cópias em um espaço particular de trabalho Fase de Validação  Verifica se as modificações realizadas pela transação não violam a serializabilidade Fase de Atualização  Se a validação tem sucesso a base é atualizada, caso contrário as modificações são descartadas

62 © José Maria Monteiro. 62 Transações Concorrentes Protocolos para Controle de Concorrência  Protocolos Otimistas Validação de T  Conjunto de objetos de T:  readSet e writeSet  OK se não há conflito de acesso entre os objetos de T e objetos de T’

63 © José Maria Monteiro. 63 Transações Concorrentes Protocolos para Controle de Concorrência  Potocolos Baseados em Lock Bloqueio  Protocolos Não Baseados em Lock Teste do Grafo de Serialização (TGS) Ordenação por “timestamp”

64 © José Maria Monteiro. 64 Transações Concorrentes Protocolo do Teste do Grafo de Serialização  Idéia: ìEvitar (prevenir) a ocorrência de ciclos no grafo ìCiclo  Schedule não é serializável por conflito  Estratégia: ìMonitoramento e gerenciamento dinâmico de um grafo que deve ser sempre acíclico

65 © José Maria Monteiro. 65 Transações Concorrentes Funcionamento do TGS  Inicialmente o GS é criado como um grafo vazio  Quando o escalonador recebe a primeira operação de uma transação T i, um nó representando T i é inserido no grafo  Para cada operação p i (x)  OP(T i ) que o escalonador recebe, ele checa se existe q j (x)  OP(T j ) que conflita com p i (x) e já escalonada.  Caso q j (x) exista: ì é incluída uma aresta da forma T j  T i

66 © José Maria Monteiro. 66 Transações Concorrentes Funcionamento do TGS  Em seguida, o escalonador verifica se a nova aresta introduz um ciclo no grafo  Em caso afirmativo, o escalonador rejeita a operação p i (x), desfaz o efeito das operações de T i e remove a aresta inserida  Caso contrário, p i (x) é aceita e escalonada

67 © José Maria Monteiro. 67 T2T2 T5T5 T1T1 T3T3 Servidor de BD Cliente A Cliente B T 1 =r T 1 (IBM) r T 1 (SUN) T 2 =w T 2 (IBM) C T 2 T 3 =r T 3 (IBM) r T 3 (SUN) T 4 = w T 4 (SUN) C T 4 T 5 = w T 5 (SUN) C T 5 IBMSUN T4T4 Transações Concorrentes Protocolo do Teste do Grafo de Serialização

68 © José Maria Monteiro. 68 T1T1 T2T2 T3T3 T4T4 T5T5 C3C3 r 1 (IBM)w 2 (IBM) C2C2 w 5 (SUN)C5C5 r 3 (IBM) r 3 (SUN) w 4 (SUN) C4C4 r 1 (SUN) C1C1 Transações Concorrentes Protocolo do Teste do Grafo de Serialização

69 © José Maria Monteiro. 69 Transações Concorrentes Problemas de Acesso Concorrente  Perda de Atualização T1T1 T2T2 read(x) x:=x-n read(x) x:=x+n A atualização de T 1 sobre x é perdida write(x) read(y) write(x) y:=y+n write(y) Tempo

70 © José Maria Monteiro. 70 Transações Concorrentes Problemas de Acesso Concorrente  Leitura Suja T1T1 T2T2 read(x) x:=x-n write(x) read(x) x:=x+n write(x) read(y) abort Se T 1 abortar, x em T 2 estará incorreto Tempo

71 © José Maria Monteiro. 71 Transações Concorrentes Problemas de Acesso Concorrente  Leitura Não Repetitível T1T1 T2T2 read(x) x:=x-n write(x) read(x) read(y) read(x) Novo acesso a x em T 2 não corresponde ao anterior Tempo

72 © José Maria Monteiro. 72 Transações Concorrentes Protocolos Baseados em Bloqueio  Idéia: ìEvitar (prevenir) a formação de ciclos no grafo  Estratégia: ìAssegura a serializabilidade controlando o acesso aos dados ìEnquanto uma transação acessa um item de dado, nenhuma outra transação pode modificar este item ìUtiliza o conceito de bloqueio

73 © José Maria Monteiro. 73 Transações Concorrentes Protocolos Baseados em Bloqueio  Tipos de Bloqueio ìBloqueio Compartilhado ou Partilhado ìSe uma transação T i obteve um bloqueio no modo compartilhado sobre o item q, então T i pode ler este item, mas não pode gravar q ìBloqueio Exclusivo ìSe uma transação T i obteve um bloqueio no modo exclusivo sobre o item q, então T i pode ler e gravar q

74 © José Maria Monteiro. 74 Transações Concorrentes Protocolos Baseados em Bloqueio  O acesso aos dados é dirigido por bloqueios ìAntes de manipular um objeto, uma transação deve obter a permissão através de um bloqueio  O lock manager mantém uma tabela de bloqueios  Função de Compatibilidade Verdadeiro Falso S S X X S  Bloqueio Compartilhado X  Bloqueio Exclusivo

75 © José Maria Monteiro. 75 Transações Concorrentes Protocolos Baseados em Bloqueio  Operações ìlock-S(q)  Bloqueio compartilhado sobre o item q ìlock-X(q)  Bloqueio exclusivo sobre o item q ìunlock(q)  Libera bloqueios sobre o item q  Funcionamento (Prot. Bloqueio Básico) ìAntes que um item q seja acessado (leitura ou escrita) por uma transação T i esta deve bloquear q ìSe q já está bloqueado em modo incompatível  T i deve esperar até que o item q esteja desbloqueado ou bloqueado em modo compatível

76 © José Maria Monteiro. 76 T1T1 T2T2 lock-X(b) read(b) write(b) lock-S(A) read(A) lock-S(b) espera unlock de b... DEADLOCK lock-X(a) espera... Tempo Transações Concorrentes Protocolos Baseados em Bloqueio  Exemplo

77 © José Maria Monteiro. 77 Transações Concorrentes Protocolos Baseados em Bloqueio  Deadlock ou Impasse ìUma transação T 1 espera por um objeto bloqueado por T 2 enquanto T 2 espera por um objeto bloqueado por T 1

78 © José Maria Monteiro. 78 T1T1 T2T2 lock-S(y) read(y) unlock(y) lock-S(x) read(x) unlock(x) lock-X(y) read(y) y = x + y write(y) unlock(y) lock-X(x) read(x) x = x + y write(x) unlock(x) Tempo Transações Concorrentes Protocolos Baseados em Bloqueio  Exemplo Schedule correto ? Schedule serializável por conflito ?

79 © José Maria Monteiro. 79 Transações Concorrentes Protocolos Baseados em Bloqueio  Exemplo ìAssuma os seguintes valores iniciais: x = 20 e y = 10 ìO schedule anterior resulta em: x = 30 e y = 30 ìExecução serial T 1  T 2 resulta em: x = 30 e y = 40 ìExecução serial T 2  T 1 resulta em: x = 40 e y = 30

80 © José Maria Monteiro. 80 Transações Concorrentes Protocolos Baseados em Bloqueio  Prot. Bloqueio Básico ìResolve ìPerda de Atualização ìLeitura Suja ìNão garante a serializabilidade por conflito

81 © José Maria Monteiro. 81 Transações Concorrentes Protocolos Baseados em Bloqueio  Bloqueio em Duas Fases (2PL) ìTransações são divididas em duas fases ìFase de expansão ìUma transação T i pode obter bloqueios ìT i não pode liberar objetos (desbloqueio) ìFase de encolhimento ìT i libera objetos (desbloqueio) ìT i não pode obter novos bloqueios

82 © José Maria Monteiro. 82 Transações Concorrentes Protocolos Baseados em Bloqueio  Bloqueio em Duas Fases (2PL) ìFuncionamento ìInicialmente, uma transação está na fase de crescimento. ìA transação adquire tantos bloqueios quantos forem necessários. ìUma vez que a transação libera um bloqueio, ela entra na fase de encolhimento e não pode mais emitir requisições de bloqueio.

83 © José Maria Monteiro. 83 T1T1 T2T2 lock-S(y) read(y) lock-X(x) lock-S(x) espera... unlock(y) read(x) x = x + y write(x) unlock(x) Tempo Transações Concorrentes Protocolos Baseados em Bloqueio  Exemplo Schedule correto ? Schedule serializável por conflito ? read(x) unlock(x) lock-X(y) read(y) y = x + y write(y) unlock(y)

84 © José Maria Monteiro. 84 T1T1 T2T2 lock-X(b) read(b) write(b) lock-S(A) read(A) lock-S(b) espera unlock de b... DEADLOCK lock-X(a) espera... Tempo Transações Concorrentes Protocolos Baseados em Bloqueio  Exemplo

85 © José Maria Monteiro. 85 Transações Concorrentes Protocolos Baseados em Bloqueio  Prot. Bloqueio em Duas Fases (2PL) ìAssegura a serializabilidade por conflito ìNão esta livre de deadlock (não é deadlock-free)

86 © José Maria Monteiro. 86 Transações Concorrentes Resolvendo Impasses (Deadlock)  Existem dois métodos principais para tratar com o problema de impasse: ìPrevenção de Impasse ìAssegura que o sistema nunca entrará no estado de impasse ìDetecção de Impasses + Recuperação ìPermite que o sistema entre num estado de impasse ìUma vez detectado um impasse então tenta recuperar

87 © José Maria Monteiro. 87 Transações Concorrentes Resolvendo Impasses (Deadlock)  As duas estratégias podem resultar em transações refeitas (aborts)  Possibilidade de aborts em cascata

88 © José Maria Monteiro. 88 Transações Concorrentes Resolvendo Impasses (Deadlock)  Prevenção de Deadlocks ìProtocolo Conservative 2PL ou Static 2PL ìRequer que cada transação bloqueie todos os seus itens de dados antes de iniciar a execução ìOu bloqueia todos os itens necessários ou não bloqueia nada ìEstratégia mais simples (prevenção de deadlocks) ìAssegura a serializabilidade ìEstá livre de deadlocks (deadlock-free) ìNão evita aborts em cascata

89 © José Maria Monteiro. 89 Transações Concorrentes Resolvendo Impasses (Deadlock)  Prevenção de Deadlocks ìProtocolo Conservative 2PL ou Static 2PL ìDesvantagens ìA utilização de um item de dado pode ser muito baixa, uma vez que os itens bloqueados podem passar longos períodos sem serem utilizados ì“Itens populares”  uma transação pode esperar indefinidamente (enfraquecimento)

90 © José Maria Monteiro. 90 Transações Concorrentes Resolvendo Impasses (Deadlock)  Prevenção de Deadlocks ìApropriação + Reexecução de Transações ìBaseado no conceito de timestamp ìTimestamp  ordem total entre as transações ìRepresentação: TS(T i ) ìSe T i começa a executar antes de T j então TS(T i ) < TS(T j ) ìDuas Técnicas Principais ìWait-Die ìWound-Wait

91 © José Maria Monteiro. 91 Transações Concorrentes Resolvendo Impasses (Deadlock)  Prevenção de Deadlocks ìWait-Die (Espere-Morra) ìSituação: ìT i tenta bloquear um objeto já bloqueado por T j ìFuncionamento: Se TS(T i ) < TS(T j ) Então T i espera Caso contrário abortar T i

92 © José Maria Monteiro. 92 Transações Concorrentes Resolvendo Impasses (Deadlock)  Prevenção de Deadlocks ìWait-Die (Espere-Morra) ìTransações mais velhas podem esperar ìTransações mais jovens são abortadas e reinicializadas com o mesmo timestamp

93 © José Maria Monteiro. 93 Transações Concorrentes Resolvendo Impasses (Deadlock)  Prevenção de Deadlocks ìWound-Wait (Machuque-Espere) ìSituação: ìT i tenta bloquear um objeto já bloqueado por T j ìFuncionamento: Se TS(T i ) < TS(T j ) Então abortar T j Caso contrário T i espera

94 © José Maria Monteiro. 94 Transações Concorrentes Resolvendo Impasses (Deadlock)  Prevenção de Deadlocks ìWound-Wait (Machuque-Espere) ìTransações mais velhas liquidam as mais jovens que são reinicializadas com o mesmo timestamp ìTransações mais jovens podem esperar

95 © José Maria Monteiro. 95 Transações Concorrentes Resolvendo Impasses (Deadlock)  Prevenção de Deadlocks ìA prevenção deve ser usada quando temos muito acesso aos dados fazendo com que a probabilidade de ocorrência de deadlocks seja alta ìOs dois esquemas evitam enfraquecimento

96 © José Maria Monteiro. 96 Transações Concorrentes Resolvendo Impasses (Deadlock)  Detecção + Recuperação de Impasses ìFuncionamento ìUm algoritmo que examina o estado do sistema é invocado periodicamente para determinar se um impasse ocorreu, ìEm caso afirmativo, o sistema precisa recuperar-se do impasse ìNecessita manter informações sobre a alocação dos itens de dados

97 © José Maria Monteiro. 97 Transações Concorrentes Resolvendo Impasses (Deadlock)  Detecção de Impasses ìGrafo Wait-For ìOs impasses podem ser descritos precisamente em termos de um grafo direcionado chamado grafo de espera.

98 © José Maria Monteiro. 98 Grafo Wait-For  Seja S um schedule sobre um conjunto de transações T = {T 1, T 2,..., T n }.  O grafo de espera para S, representado por G(S), é definido como: O grafo direcionado G(S) = (N,A) Cada nó em N representa uma transação em T O conjunto A contém as arestas na forma T i  T j, se e somente se a transação T i está esperando por T j. Transações Concorrentes

99 © José Maria Monteiro. 99 Transações Concorrentes Grafo Wait-For  Funcionamento:  Quando T i requer um item de dado que está sendo mantido pela transação T j. Então uma aresta na forma T i  T j é inserida no grafo de espera.  Esta aresta é removida apenas quando a transação T j não mantiver nenhum item de dado requisitado por T i.

100 © José Maria Monteiro. 100 Transações Concorrentes Resolvendo Impasses (Deadlock)  Detecção de Impasses  Teorema:  Um impasse existe no sistema se e somente se o grafo de espera (wait-for) apresenta um ciclo.  Algoritmo  Verificar a existência de ciclo no grafo.

101 © José Maria Monteiro. 101 Transações Concorrentes Resolvendo Impasses (Deadlock)  Detecção de Impasses  Quando invocar o algoritmo de detecção ???  Com que freqüência ocorrem os conflitos ?  Quantas transações serão afetadas por um conflito ?

102 © José Maria Monteiro. 102 Transações Concorrentes Resolvendo Impasses (Deadlock)  Recuperação de Impasse  Quando o algoritmo de detecção determina que existe um impasse (ciclo no grafo), o sistema precisa recuperar-se.  Solução :  Reiniciar uma das transações envolvidas no ciclo

103 © José Maria Monteiro. 103 Transações Concorrentes Resolvendo Impasses (Deadlock)  Recuperação de Impasse  Selecionar uma vítima  Determinar a transação que resultaria em um custo mínimo.  Perigo de Enfraquecimento (livelock)  Incluir o número de repetições no fator custo

104 © José Maria Monteiro. 104 Transações Concorrentes Protocolos Baseados em Bloqueio  Strict 2PL ìUma transação T i não libera nenhum bloqueio até executar seu commit ou abort ìNenhuma transação pode ler ou escrever um item que foi “escrito” por T i até que T i commit ou abort ìA liberação dos bloqueios é realizada globalmente no fim da transação ìAssegura a serializabilidade por conflito ìEvita aborts em cascata ìNão esta livre de deadlock a não ser que seja combinado com o protocolo conservative 2PL

105 © José Maria Monteiro. 105 Transações Concorrentes Protocolos Baseados em Marcadores de Tempo  Ordenação por Timestamp (TO) ìUtiliza marcadores de tempo a fim de ordenar a execução das transações gerando um schedule equivalente a algum schedule serial ìA ordem de execução das transações é determinada pela ordem em que as transações são iniciadas ìTimestamp – TS(T) ìÉ um identificador único criado pelo SGBD para identificar uma transação ìEm geral, os valores são gerados na ordem em que as transações são submetidas ao sistema

106 © José Maria Monteiro. 106 Transações Concorrentes Protocolos Baseados em Marcadores de Tempo  Ordenação por Timestamp (TO) ìGeração dos Timestamps ìNúmero seqüencial (1,2,3...) ìData+Hora ìO schedule gerado é equivalente a um determinado (particular) schedule serial ìCorresponde a ordem dos timestamps

107 © José Maria Monteiro. 107 Transações Concorrentes Protocolos Baseados em Marcadores de Tempo  Ordenação por Timestamp (TO) ìFuncionamento ìO algoritmo associa a cada item X do BD dois timestamps: ìRead_TS(X): Maior entre todos os timestamps de transações que leram o item X. ìWrite_TS(X): Maior entre todos os timestamps de transações que modificaram o item X ìQuando uma transação Ti deseja ler ou escrever sobre o item X, o algoritmo compara o timestamp de Ti com o Read_TS(X) e Write_TS(X)

108 © José Maria Monteiro. 108 Transações Concorrentes Protocolos Baseados em Marcadores de Tempo  Ordenação por Timestamp (TO) ìProtocolo 1. T solicita uma operação write(x) Se Read_TS(X) > TS(T) ou Write_TS(X) > TS(T) Então abortar T Se não executar write(x) e fazer TS(x) = TS(T) 2. T solicita uma operação read(x) Se Write_TS(X) > TS(T) Então abortar T Se não executar read e fazer Read_TS(x) = Max(Read_TS(x), TS(T))

109 © José Maria Monteiro. 109 Transações Concorrentes Protocolos Baseados em Marcadores de Tempo  Ordenação por Timestamp (TO) ìSerializabilidade ìOperações conflitantes sempre são executadas na ordem dos timestamps das transações ìNão utiliza bloqueios ìDeadlocks não podem ocorrer (deadlock-free) ìNão evita aborts em cascata

110 © José Maria Monteiro. 110 Transações Concorrentes Confiabilidade de Schedules Propriedades das Transações

111 Recuperação em Sistemas de Bancos de Dados José Maria Monteiro Universidade Federal do Ceará Departamento de Computação

112 © José Maria Monteiro. 112 Visão Geral Introdução Conceitos Básicos Atualização Adiada Atualização Imediata Páginas Sombra Conclusões

113 © José Maria Monteiro. 113 Introdução

114 © José Maria Monteiro. 114 Introdução Um sistema de computador está sujeito a falhas Uma falha pode ter diferentes causas Defeito no disco (HD) Queda de energia Erros de software Sabotagem Em caso de falha As informações armazenadas no SGBD são perdias Leva o SGBD a um estado inconsistente

115 © José Maria Monteiro. 115 Conceitos Básicos

116 . Esquema de Recuperação Módulo do SGBD responsável pela detecção de falhas e pela restauração do banco de dados a um determinado estado consistente anterior à ocorrência da falha.

117 © José Maria Monteiro. 117 Classificação das Falhas Falha de mídia (caótica) Falha no disco Incêndio,... Falha de execução (base inconsistente) Erros lógicos Erros do sistema Queda e energia

118 © José Maria Monteiro. 118 Algoritmos de Recuperação Em geral, apresentam duas partes. 1. Ações tomadas durante o processamento normal das transações.  Assegurar que informações suficientes existam para permitir a recuperação do banco após a ocorrência de uma falha. 2. Ações tomadas após a ocorrência da falha.  Assegurar a consistência do banco de dados.

119 © José Maria Monteiro. 119 Recuperando Falhas de Mídia Copiar periodicamente o conteúdo inteiro do banco de dados para meio estável (backup) Reconstruir uma cópia da base a partir de arquivo morto (quando ocorrer uma falha) A cópia mais recente deve ser utilizada na restauração O banco de dados volta a um determinado estado consistente anterior à ocorrência da falha

120 © José Maria Monteiro. 120 Recuperando Falhas de Execução Estratégias baseadas em LOG Atualização Adiada Atualização Imediata Páginas Sombra ou Paginação Imagem

121 © José Maria Monteiro. 121 Estratégias Baseadas em LOG

122 © José Maria Monteiro. 122 Transação Lê e atualiza os itens de um banco de dados Unidade de Consistência ou Atomicidade Exemplo: Transferência de saldo entre duas contas Transação abortada  Desfazer ações ( RollBack ) O BD precisa der restaurado ao estado que se encontrava logo antes da transação ter sido iniciada

123 © José Maria Monteiro. 123 Transação Solução inicial  Reexecutar a transação abortada  Não reeexecutar a transação abortada As duas opções levam a estados inconsistentes

124 © José Maria Monteiro. 124 O Jornal Codnome: LOG Mantém registro das ações transacionais Informações usadas para reconstrução após falha Armazenado em disco Backup periódico

125 © José Maria Monteiro. 125 O Jornal Toda vez que uma transação executa uma escrita  É necessário que o registro Log esteja gravado (persistente) antes que o banco seja modificado Problemas  O volume do Log  Quando é seguro apagar informações no Log ??

126 © José Maria Monteiro. 126 Entradas do Jornal [T i, Start] [T i, Item, Valor_Antigo, Valor_Novo] [T i, Item, Valor_Lido] [T i, Commit] [T i, Abort] [Checkpoint]

127 © José Maria Monteiro. 127 Atualização Adiada

128 © José Maria Monteiro. 128 Atualização Adiada Durante a execução das transações  Modificações sobre os itens de dados são realizadas em espaço de trabalho particular  Modificações são registradas no jornal  Adia-se a execução das operações de escrita de uma transação até que esta esteja parcialmente executada

129 © José Maria Monteiro. 129 Funcionamento Antes que T i inicie sua execução, um registro [T i, Start] é escrito no log A cada operação de escrita write(X, X j )  T i um novo registro é gravado no log Quando T i é parcialmente executada, um registro [T i, Commit] é escrito no log Em seguida, os registros associados a T i no log são usados para atualizar o BD e T i entra no estado executado

130 © José Maria Monteiro. 130 Atualização Adiada Algoritmo no-undo/redo 1. Usar duas listas de transações - Transações Validadas  ([T i, Start] + [T i, Commit]) - Transações Ativas  Somente ([T i, Start]) 2. Aplicar redo às modificações das transações validadas seguindo a ordem de gravação no jornal 3. Re-iniciar as transações ativas

131 © José Maria Monteiro. 131 Atualização Adiada Redo 1. Examinar registros no jornal: [T i, X, Valor_Antigo, Valor_Novo] 2. Atualizar X na base usando Valor_Novo NB. A operação Redo deve ser idempotente.

132 © José Maria Monteiro. 132 Atualização Imediata

133 © José Maria Monteiro. 133 Atualização Imediata Durante a execução das transações  Modificações sobre os itens de dados são realizadas diretamente sobre o banco de dados (Modificações descomprometidas)  Modificações são registradas no jornal Em caso de falha  O log é utilizado para restaurar os itens de dados modificados aos valores que tinham antes do início da transação

134 © José Maria Monteiro. 134 Funcionamento Antes que T i inicie sua execução, um registro [T i, Start] é escrito no log A cada operação de escrita write(X, X j )  T i um novo registro é gravado no log Quando T i é parcialmente executada, um registro [T i, Commit] é escrito no log

135 © José Maria Monteiro. 135 Atualização Adiada Algoritmo undo/redo 1. Usar duas listas de transações - Transações Validadas e Transações Ativas 2. Aplicar undo às transações ativas - Seguindo a ordem inversa de gravação no jornal 3. Aplicar redo às transações validadas - Seguindo a ordem de gravação no jornal

136 © José Maria Monteiro. 136 Undo 1. Examinar registros no jornal: [T i, X, Valor_Antigo, Valor_Novo] 2. Atualizar X na base usando Valor_Antigo NB. A operação Undo deve ser idempotente. Atualização Adiada

137 © José Maria Monteiro. 137 Checkpoint Quando uma falha ocorre é necessário consultar o log para determinar as transações validadas e ativas Em princípio, o log inteiro precisa ser percorrido  Este processo consome tempo  Grande parte das transações validadas já têm suas atualizações escritas no banco de dados

138 © José Maria Monteiro. 138 Checkpoint 1. Suspende a execução de todas as transações 2. Força a gravação em disco dos efeitos das operações das transações validadas 3. Escreve uma entrada [Checkpoint] no jornal 4. Força a gravação do jornal em disco 5. Re-ativa transações suspensas

139 © José Maria Monteiro. 139 Checkpoint [T i, Commit] antes de [Checkpoint] :  Não há necessidade de refazer T i Quando efetuar o Checkpoint ???  Tempo  Número de transações validadas

140 © José Maria Monteiro. 140 Páginas Sombra

141 © José Maria Monteiro. 141 Páginas Sombra O BD é dividido em determinado número de blocos com comprimento fixo, os quais são chamados de páginas Para encontrar uma determinada página  Utiliza uma tabela de páginas (Índice) com “n” entradas, uma para cada página  Cada entrada contém um ponteiro para uma página no disco

142 © José Maria Monteiro. 142 Páginas Sombra Idéia básica:  Manter duas tabelas de páginas durante a vida de uma transação Tabela de Página Corrente Tabela de Página Sombra ou Imagem  Quando a transação inicia as tabelas de página são idênticas

143 © José Maria Monteiro. 143 Páginas Sombra  A tabela de página sombra nunca é alterada durante a execução de uma transação  A tabela de página corrente é alterada quando uma transação executa uma operação de escrita  Leituras e escritas usam a tabela corrente  A tabela de página sombra é armazenada em meio estável para que o estado do banco possa ser recuperado em caso de falha

144 © José Maria Monteiro. 144 Páginas Sombra  Quando a transação validar A tabela de página corrente será gravada no disco A tabela de página corrente torna-se a nova torna- se a nova tabela de página imagem  Em caso de falha  O estado do banco é recuperado utilizando-se a página imagem

145 © José Maria Monteiro. 145 Páginas Sombra Considerações:  Sob certas circunstâncias, pode requerer menos acesso a disco do que os métodos baseados em log  Em caso de falha a recuperação é mais rápida Desvantagens  Fragmenteção de dados  Mais difícil de implementar em ambientes de transações concorrentes

146 © José Maria Monteiro. 146 Conclusões O esquema de recuperação é um módulo essencial em Sistemas de Bancos de Dados A escolha da estratégia de recuperação a ser utilizada é influenciada pelas características das aplicações


Carregar ppt "Sistemas de Gerenciamento de Bancos de Dados José Maria Monteiro Universidade Federal do Ceará Departamento de Computação"

Apresentações semelhantes


Anúncios Google