Recuperao aps falhas SISTEMAS DE GERENCIAMENTO DE BANCO

Recuperação após falhas SISTEMAS DE GERENCIAMENTO DE BANCO – UFPE DECIN DADOS Hélder Lima e Silva - hmls hélder manoel lima e silva

Recuperação após falhas 1. 2. 3. 4. 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 5. descuido do operador ▷ destruição dos dados de forma não intencional 6. sabotagem ▷ destruição intencional dos dados hélder manoel lima e silva

Recuperação após falhas 1. Impossibilidade de recuperar os dados 2. BD inconsistente BACKUP Undo/Redo hélder manoel lima e silva

Recuperação após falhas § Transações e Recuperação transação: unidade de recuperação de um BD BUFFER MEMÓRIA SECUNDÁRIA hélderwriting manoel lima e a gravação explícita do buffer no disco chama-se force silva

Recuperação após falhas UNDO/RE DO hélder manoel lima e silva

Recuperação após falhas 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 hélder manoel lima e silva

Recuperação após falhas 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 hélder manoel lima e consolidada silva

Recuperação após falhas backup Recursos para recuperação 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 hélder manoel lima e silva

Recuperação após falhas 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) hélder manoel lima e silva

Recuperação após falhas 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 BD 2. Escreve os blocos modificados no buffer do para a memória secundária 3. Escreve uma entrada do tipo checkpoint no arquivo de log hélder manoel lima e silva

Recuperação após falhas 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. hélder manoel lima e silva

Recuperação após falhas 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. hélder manoel lima e silva

Recuperação após falhas UNDO/RE DO hélder manoel lima e silva

Recuperação após falhas 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 hélder manoel lima e silva

Recuperação após falhas Estratégias de recuperação § adiada (BD atualizado depois do commit) o o o antes do commit: atualizações em memória principal depois do commit: log disco undo desnecessário hélder manoel lima e silva

recuperação adiada protocolo: Recuperação após falhas 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 hélder manoel lima e vezes silva

Recuperação após falhas Estratégias de recuperação § imediata (BD atualizado antes do commit) o o gravação no log antes do BD undo/redo ou undo/no-redo hélder manoel lima e silva

recuperação imediata Recuperação após falhas 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 hélder manoel lima e BD. silva

Shadow paging Recuperação após falhas 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 1. Elimina OVERHEAD para manter o arquivo de log 2. Recovery mais rápido 3. Nem UNDO, nem REDO. Desvantagens 1. fragmentação 2. Necessidade de garbage collection hélder manoel lima e silva

Recuperação após falhas FIM hélder manoel lima e silva

Recuperação após falhas hélder manoel lima e silva