Roteiro. Noções de Recuperação de Falhas. BCC321 - Banco de Dados I. Ementa. Posicionamento

Transcrição

1 Roteiro Noções de Recuperação de Falhas Posicionamento Luiz Henrique de Campos Merschmann Departamento de Computação Universidade Federal de Ouro Preto Introdução Conceitos de Recuperação Técnicas de Recuperação Referências BCC321 - Banco de Dados I Introdução Ementa 1. Conceitos básicos em sistemas de banco de dados. 2. Conceitos e arquitetura de sistemas de banco de dados. 3. Modelagem conceitual de dados. 4. Modelo Relacional: conceitos básicos e restrições de integridade. 5. Linguagens: álgebra e cálculo relacional. 6. A linguagem SQL e o uso de APIs. 7. Projeto de banco de dados. 8. Normalização de banco de dados. 9. Noções de processamento de transações, concorrência e recuperação de falhas. 10. Aspectos de implementação de banco de dados. Falhas de banco de dados podem acontecer por diferentes motivos. Discutiremos sobre diferentes abordagens para recuperação de falhas. As técnicas de recuperação estão relacionadas com os métodos de controle de concorrência.

2 Restauração de Falhas Tipos de Falhas (continuação...) Qual a sua importância? Uma transação pode falhar durante sua execução. O sistema de banco de dados deverá manter informações sucientes para se recuperar dessa falha. Tipos de falhas que podem ocorrer: O computador falhar: erro de hardware, software ou rede. Ex.: memória principal. Erro de transação ou sistema: alguma operação da transação pode causar falha. Ex.: divisão por zero. Erros locais ou condições de exceção detectadas pela Imposição do controle de concorrência: método de controle de concorrência pode abortar uma transação. Ex.: transações em estado de deadlock. Falha de disco: mau funcionamento de uma leitura ou gravação. Problemas físicos e catástrofes: problemas como falta de energia, fogo, sabotagem, etc. transação: determinadas condições provocam o cancelamento da transação. Ex.: dados não encontrados. O Log do sistema Esquema de Recuperação Recuperação de transações: o banco de dados será restaurado para o estado de consistência mais recente. Para poder se recuperar de falhas que afetam as transações, o sistema mantém um log. O log é mantido em disco, de modo que não será afetado por nenhum tipo de falha, exceto falha de disco ou catastróca. O log é periodicamente copiado para um sistema de armazenamento (ta). Estratégia típica para recuperação: Não houver dano físico (falha não catastróca): Reverter (desfazer operações) quaisquer mudanças que causaram as inconsistências. Refazer algumas operações de forma a restaurar um estado consistente do banco. Dano em grande porção do banco de dados (falha catastróca): Restauração com cópia anterior do banco (armazenada em ta). Reconstrução num estado mais atual refazendo as operações armazenadas no log (armazenado em ta).

3 Técnicas de Recuperação Técnicas de Recuperação de Falhas Não-Catastrócas: Técnicas de recuperação baseadas em atualização adiada. Técnicas de recuperação baseadas em atualização imediata. Técnicas de Recuperação de Falhas Catastrócas. Idéia: postergar qualquer atualização real (gravar em disco) no banco de dados até que a transação complete sua execução com sucesso e alcance o ponto de efetivação. Durante a execução da transação: atualizações registradas no log e nos buers. Após alcançar o ponto de efetivação e forçar a gravação do log no disco, as atualizações são registradas no banco de dados. Algoritmo NO-UNDO/REDO: Protocolo típico de atualização adiada: Uma transação não pode alterar o banco em disco até que ela alcance seu ponto de efetivação. Uma transação não alcança seu ponto de efetivação até que todas as suas operações sejam registradas no log e até que seja forçada a gravação do log no disco. Como o banco nunca é atualizado em disco até que a transação seja efetivada, nunca será necessária qualquer operação UNDO (desfazer). REDO (refazer) será necessário no caso de o sistema falhar depois que a transação for efetivada, mas antes de todas as suas alterações serem gravadas em disco (utilização do log). Log Banco de Dados Nenhuma ação refazer (REDO) tem que ser tomada, já que <T0, A, 950> nenhum registro de efetivação <T0, B, 2050> aparece no log. A = 950 falha, a operação REDO(T0) é realizada, já que o registro < T0 commit > aparece no log.

4 O banco de dados pode ser atualizado por algumas Algoritmo de recuperação UNDO/NO-REDO. operações de uma transação antes que ela alcance seu ponto de efetivação. No entanto, a atualização também deve ser registrada no log (em disco) antes de sua aplicação no banco de dados, Log <T0, A, 1000, 950> Banco de Dados falha, ele encontra no log < T0 start >, mas não < T0 commit >. Portanto, será processado um UNDO(T0) tornando possível a recuperação. Se uma transação falhar depois de registrar mudanças no banco de dados, mas antes de alcançar seu estado de <T0, B, 2000, 2050> A = 950 Se a técnica de recuperação garantir que todas as atualizações de uma transação são registradas no banco de dados (em disco) efetivação, os efeitos de suas operações no banco deverão ser desfeitos (UNDO). antes da efetivação da transação, nunca haverá necessidade de refazer quaisquer operações das transações efetivadas. Perguntas Algoritmo de recuperação UNDO/REDO. Log <T0, A, 1000, 950> <T0, B, 2000, 2050> Banco de Dados A = 950 falha, ele encontra no log < T0 start >, mas não < T0 commit >. Portanto, será processado um UNDO(T0) Se a técnica de recuperação permitir que a transação se efetive antes que todas as suas operações sejam escritas no banco de dados, necessitaremos da operação REDO.

5 Referências Ramez Elmasri e Shamkant B. Navathe, Sistemas de Banco de Dados, 4 o edição, Editora Pearson, Abraham Silberschatz, Henry F. Korth e S. Sudarshan, Sistema de Banco de Dados, 3 o edição, Editora Pearson, C. J. Date, Introdução a Sistemas de Bancos de Dados, Editora Elsevier, FIM