SISTEMAS DE GERENCIAMENTO DE BANCO DE DADOS Hélder Lima e Silva - hmls

Apresentação em tema: "SISTEMAS DE GERENCIAMENTO DE BANCO DE DADOS Hélder Lima e Silva - hmls"— Transcrição da apresentação:

1 SISTEMAS DE GERENCIAMENTO DE BANCO DE DADOS Hélder Lima e Silva - hmls
Recuperação após falhas SISTEMAS DE GERENCIAMENTO DE BANCO DE DADOS CIN – UFPE Hélder Lima e Silva - hmls

2 system crash ▷ perda da memória principal
falha de mídia ▷ perda da memória secundária erros em aplicativos ▷ erro lógico no aplicativo desastres naturais/físicos ▷ incêndios, terremotos, blecautes descuido do operador ▷ destruição dos dados de forma não intencional sabotagem ▷ destruição intencional dos dados

3 Impossibilidade de recuperar os dados
BD inconsistente BACKUP Undo/Redo

4 Transações e Recuperação
transação: unidade de recuperação de um BD a gravação explícita do buffer no disco chama-se force writing MEMÓRIA SECUNDÁRIA BUFFER

5 UNDO/REDO

6 Gerenciamento de buffer
estratégias de relocação: FIFO/LRU alternativa: utilizar 2 variáveis pincount e dirty inicializadas com 0 Quando uma requisição de página ocorre, o gerenciador de buffer verifica se a página já está em um buffer do SGBD. Se não estiver: 1. Usar a estratégia de relocação; Incrementar o pincount (impede a escrita da página no disco A estratégia não pode escolher um buffer pinado 2. Se a variável dirty estiver TRUE então ele gravará o buffer no disco 3. Lê a página no disco Coloca no buffer escolhido e Faz dirty = FALSE

7 Gerenciamento de buffer
terminologias steal policy Permite ao gerenciador de buffer escrever no disco antes do commit da transação. Alternativa: NO-STEAL force policy Garante que todas as páginas atualizadas por uma transação são escritas no disco quando a transação chega no commit . Alternativa: NO-FORCE IMPLEMENTAÇÃO MAIS SIMPLES: NO-STEAL/FORCE undo desnecessário e redo desnecessário para transações consolidadas (commited) IMPLEMENTAÇÃO MAIS USADA: STEAL/NO-FORCE steal evita necessidade de buffer’s muito grandes e no-force evita reescrita de páginas que não foram utilizadas por uma transação mais nova e não consolidada

8 Recursos para recuperação
backup faz cópias periodicamente do BD logging guarda caminho do estado atual das transações e modificações no BD checkpoint permite que atualizações ao banco se tornem permanentes. gerenciador de recuperação permite ao sistema restaurar o BD para um estado consistente

9 Recursos para recuperação
BACKUP fita magnética LOGGING não é usado apenas para recovery (monitoramento de performance) pode conter: 1. entrada de transações identificador tipo de entrada (start, insert, delete, update, commit) identificador do item de dado afetado imagem antiga do item de dade afetado imagem nova informações de manutenção do log 2. checkpoints (o ponto de sincronização entre o BD e o log)

10 Recursos para recuperação
CHECKPOINT Envolve as seguintes operações: 1. Escrever todas as entradas do log de memória principal para a secundária 2. Escreve os blocos modificados no buffer do BD para a memória secundária 3. Escreve uma entrada do tipo checkpoint no arquivo de log

11 Recursos para recuperação
CHECKPOINT transações em série  falha Verificar o arquivo de log para encontrar a última transação iniciada antes do último checkpoint. Qualquer transação anterior já foi escrita no BD. Aplicar REDO para as transações ativas e com entradas do tipo start e commit no log.

12 Recursos para recuperação
CHECKPOINT transações concorrentes  falha Refazer (REDO) as transações depois do checkpoint e desfazer todas as transações ativas no momento da falha.

13 UNDO/REDO

14 Técnicas de Recuperação
Dependem da extensão do dano no BD Dois casos: 1. BD AMPLAMENTE DANIFICADO * restaurar o último backup * reaplicar as alterações das transações comitadas a partir do arquivo de log 2. BD NÃO FOI FISICAMENTE DANIFICADO MAS TORNOU-SE INCONSISTENTE * atualização adiada * atualização imediata * shadow

15 Estratégias de recuperação
adiada (BD atualizado depois do commit) antes do commit: atualizações em memória principal depois do commit: log  disco undo desnecessário

16 recuperação adiada protocolo:
1. quando uma transação se inicia, escrever uma entrada transaction start no log; 2. quando qualquer operação de escrita for executada, escrever uma entrada de log. Não atualizar buffer e BD; 3. quando a transação está prestes a se consolidar, escrever uma entrada transaction commit no log. Escrever todas as entradas do log no disco. Depois consolidar a transação. Usar as entradas no log para executar as atualizações no BD 4. qualquer transação com entradas no log do tipo transaction start e transaction commit deverão sofrer REDO. O procedimento de REDO executa as escritas no BD usando as entradas IMdepois no log das transações na mesma ordem que elas entraram no log; 5. para qualquer transação com entradas no log do tipo transaction start e transaction abort no log, nada precisa ser desfeito, pois as atualizações não chegaram a ser escitas no BD * Se uma segunda falha ocorre durante a recuperação, as entradas no log podem ser usadas novamente para recuperar o BD, não importa quantas vezes

17 Estratégias de recuperação
imediata (BD atualizado antes do commit) gravação no log antes do BD undo/redo ou undo/no-redo

18 recuperação imediata protocolo:
1. quando uma transaçào se inicia, escrever uma entrada transaction start no log; 2. quando qualquer operação de escrita for executada, escrever uma entrada de log; 3. uma vez que o log é escrito, atualizar o buffer; 4. as atualizações no BD serão escritas automaticamente, quando os buffers são escritos no disco; 5. quando a transação se consolidar, escreva uma entrada do tipo transaction commit no log; 6. para qualquer transação do tipo transection start e transaction commit aplicar REDO para escrever a IMdepois dos campos atualizados; 7. para as transações com entradas do tipo transaction start mas sem transaction commit, será necessário desfazer a transação (escrever as IMantes nos itens afetados.) A soperações de UNDO são realizadas na ordem inversa a que aparecem no log * É essencial que as entradas no log sejam escritas antes da escrita correspondente no BD.

19 Shadow paging Vantagens Desvantagens protocolo:
1. mantém duas páginas durante a vida da transação (página atual e página sombra) Quando a transação começa, as duas páginas são idênticas. Durante a transação, a página atual é utilizada para gravar todas as atualizações no BD. Quando uma atualização se completa a página atua se torna a página sombra Vantagens Elimina OVERHEAD para manter o arquivo de log Recovery mais rápido Nem UNDO, nem REDO. Desvantagens fragmentação Necessidade de garbage collection

20 FIM

21