Recuperação após falha

1. Recuperação após falha Lílian Simão Oliveira

2. Motivação • Sistema de computador está sujeito a falhas • Existem diversos tipos de falhas, as quais podem acarretar perda dos dados • O sistema deve garantir que as propriedades de atomicidade e durabilidade das transações sejam preservadas Transações Falha BD Consistente BD Inconsistente Técnicas de Recuperação

3. Conceitos Básicos • Transação • Unidade de trabalho; Unidade de recuperação • As propriedades devem ser preservadas • Recuperação • O SGBD é acionado automaticamente para resolver os tipos de falhas esperados • Condição básica • Armazenamento de informação redundante durante o funcionamento normal (log, backup) • Estado do BD deve ser recuperado • Ao mais recente estado consistente antes da falha (satisfaz todas as restrições de integridade)

4. Observe • O planejamento e o processo de BackUp geralmente envolve a seguinte questão: • Isto porque é preciso conhecer o funcionamento do gerenciador de recuperação, determinar a frequência com que será feito o Backup e onde ele ficará armazenado • No pior caso, se o backup estiver guardado próximo a máquina com os dados e a sala que eles estiverem pegar fogo.... Quanto você está disposto a perder?

5. Meios de Armazenamento • Volátil • Buffer • Os dados estão armazenados na memória principal do computador • Acesso mais rápido • A informação residente neste meio usualmente, não sobrevive a quedas no sistema • Não-volátil • Os dados estão armazenados em discos e/ou fitas • A informação residente neste meio sobrevive a quedas no sistema mas pode não sobreviver a falhas neste meio • Estável • A informação residente neste meio “nunca” é perdida • Meio mais seguro do que a não-volátil

6. Implementação de armazenamento estável • Backups em fitas em diferentes locais • Mas atualizações ocorridas entre o desastre e o último backup podem ser perdidas • Sistemas mais seguros • Cópia de cada bloco estável em um site remoto • Cópia onthefly

7. Implementação de armazenamento estável • Transferência de blocos entre MP e disco pode resultar em: 1. Conclusão bem sucedida: informação chegou de forma segura ao destino 2. Falha parcial: falha ocorreu no meio da transferência e o bloco de destino contém informação incorreta 3. Falha total: falha ocorreu cedo o suficiente, de modo que o bloco de destino permanece intacto

8. Implementação de armazenamento estável • Uma operação de saída é executada como segue: • Escreve a informação dentro do primeiro bloco físico • Quando a primeira escrita se completar com sucesso, escreve a mesma informação no segundo bloco físico • A saída é completada somente após a segunda escrita completar‐se com sucesso • Assegura que uma escrita em armazenamento estável seja bem sucedida • Ou todas as cópias são atualizadas ou não resulte em mudança alguma (atomicidade) • Embora o uso de grande número de cópias reduza a probabilidade de uma falha em geral é suficiente simular armazenamento estável com duas cópias

9. Implementação de armazenamento estável • Na ocorrência de falhas na transferência, o sistema deve • Detectar falha • Chamar procedimento de recuperação • Restabelecer o bloco, levando‐o a um estado consistente • Para isso, o sistema deve manter dois blocos físicos para cada bloco lógico do BD • No caso de discos espelhados: ambos no mesmo local • No caso de backup remoto: um é local, outro está num site remoto

10. Recuperação/Tolerânciaa Falhas • O valor da informação disponível numa BD torna importante que esta esteja permanentemente num estado de integridade ou, se tal não for possível, que a sua indisponibilidade ocorra num curto espaço de tempo e que se faça a sua reposição para um estado de integridade.

11. Recuperação/Tolerânciaa Falhas • A recuperação/tolerância a falhas tem por objectivo restaurar a BD para um estado de integridade, após a ocorrência de uma falha; • Os mecanismos de recuperação baseiam-se na utilização de formas de redundância que quase duplicam a BD, utilizando: • Backup e transaction log

12. Recuperação/Tolerânciaa Falhas • Os backupssãocópias de segurançada BD, quesãoexecutadosperiodicamente e constituem um ponto de partidapara a recuperaçãoda BD após a ocorrência de umafalha, independentementedasuagravidade; • Refletemumasituaçãopassada, donde a reposição a partir de um backupimplicaperdertodas as actualizaçõesposteriores à realização do mesmo.

13. Recuperação/Tolerânciaa Falhas • Uma forma de minimizar esta situação é aumentando a periodicidade dos backups, o que é um processo pesado, consumidor de recursos e que pode obrigar a paragens dos sistemas; • A periodicidade dos backups depende do valor dos dados, do seu volume e da frequência com que são acedidos e alterados;

14. Recuperação/Tolerânciaa Falhas • O backup é um mecanismo de reposição da BD. Os transaction logs são mecanismos de repetição das transacções ocorridas desde o último backup (rollforward); • Normalmente para se refazer uma transacção é necessário o ficheiro de transaction log, onde está guardada uma identificação da transacção e uma cópia dos dados actualizados por ela (after image);

15. Recuperação/Tolerânciaa Falhas • Sendo esta a forma mais comum de resolver os problemas provocados por uma falha, têm que existir outros mecanismos que permitam o roll back das transacções não terminadas, ocorridos durante a execução não sucedida das mesmas; • Donde o ficheiro transaction log necessita igualmente de guardar os dados anteriores ao início da execução da transacção (before-images)

16. Recuperação/Tolerânciaa Falhas • É da conjugação destes dois mecanismos - backups e transaction logs , que se garantem duas das características fundamentais das transacções: • Atomicidade (desfazendo uma transacção não sucedida) • Persistência (refazendo os efeitos de uma transacção bem sucedida)

17. Idéia Básica: Registrar • Armazenar informações de REFAZER e DESFAZER, para cada atualização, em um log. • Escritas seqüenciais em um log (manter em um disco separado). • Mínimo de informações (diferenças) gravadas no log, tal que várias atualizações cabem em uma única página. • v Log: Lista ordenada de ações REFAZER/DESFAZER • Um registro do log contém: • <ID_transação, ID_página, deslocamento, tamanho, dado_antigo, dado_novo> • E informações adicionais de controle (que veremos adiante).

18. Recuperação usando Log • Arquivo onde ficam armazenadas todas as operações realizadas no BD • Cada vez que é executada uma operação sobre uma linha de uma tabela é criado uma entrada (ou registro) no Log • Exemplos de registros no Log: • [begin_Transaction, T] • [write, T, X, old, new] • [read, T, X] • [commit, T] • [abort, T]

19. Log • Armazenado na memória principal, em meio não-volátil e em meio estável • É um arquivo serial que guarda todas as modificações que foram realizadas no BD e quais transações realizaram quais modificações • Este arquivo é lido durante o processo de recuperação pois pode levar um BD ao seu último estado consistente antes da falha • Uma transação só é considerada executada quando todos os registros do Log destatransação estiverem armazenadas no banco de dados físico • Registros do Log devem ser armazenados no arquivo na ordem em que eles foramcriados (exemplo: antes que o registro <commit, Ti> seja armazenado no arquivo, todos osoutros registros desta transação já devem estar)

20. Recuperação de Falha de Transação • Deve ser executada pelo SGBD quando • uma transação que estava sendo executada é cancelada (explícita/implícitamente) • Recuperação • Os efeitos da transação em questão devem ser desfeitos • Para isso, deve-se varrer o arquivo de Log para identificar as operações já realizadas pela transação

21. Recuperação de Falha do Sistema • O SGBD parou de executar • Operações que estavam na memória volátil não foram armazenadas na memória física • Consequentemente • Todas as transações que estavam em execução no momento da falha devem ser desfeitas • Questão: • Como o SGBD sabe as transações que estavam em execução? Deverá varrer todo o Log?

22. Tipos Falhas • Falha de transação • Erro lógico. A transação não pode continuar sua execução normal devido a alguma condição não satisfeita • Erro de sistema. O sistema entrou em um estado inadequado (deadlock) • Falha do sistema • Queda de energia. Não danifica fisicamente o BD, mas as informações em memória volátil são perdidas. Afeta todas as transações em curso no momento • Falha de Mídia • Bloco de disco perdeu conteúdo em função da quebra do cabeçote ou falha durante a transferência de dados. Danifica fisicamente o BD

23. Requisitos dos SGBDTipo de Falhas Falha de disco - o(s) disco(s) onde a BD estáarmazenadafica(m) inutilizado(s). É a falhaconsideradamais grave e queobriga à reconstrução de todo o SGBD; Solução: Refazer o BD utilizando um BD espelho ou uma cópia de segurança Falha de sistema - poderesultar de problemas de hardware ou software, nãosendopossívelgarantir a validade dos dados. Implicarepor a BD a partir do seuúltimoestado de integridade. Solução: Recuperar o mais recente estado consistente do BD que existia antes da falha • Refazer ou desfazer transações

24. Requisitos dos SGBDTipo de Falhas • Falha de transação- é a maisinofensiva e recupera-se recorrendoaoficheirotransaction log e as before imagesdatransacçãoquenãofoibemsucedida. Solução: Desfazer as operações já realizadas pela transação até o início da transação ou até um determinado ponto dentro da transação • Emqualquerprocesso de recuperaçãorecorre-se aorollback das transaçõesefetuadasatéaomomentoemqueostransaction log e osficheriosda base estãosincronizados, para se poderemdesfazertodas as transacçõesdecorridasdesdeentão.

25. Requisitos dos SGBDTipo de Falhas • Esse momento coincide com o último backup, o qual se muito afastado no tempo, obriga a um processo moroso e complexo de recuperação da BD. Tn Tn+1 Tn+2 Tn+3 Falha de disco Último backuo

26. Requisitos dos SGBDTipo de Falhas • Para evitar este tipo de situações, recorre-se a marcas de segurança, conhecidas por checkpoints. • Basicamente, para reduzir o número de acessos aos discos, nos ficheiros de transaction log as actualizações são realizadas na memória RAM, em buffers, sendo posteriormente escritos em disco;

27. Requisitos dos SGBDTipo de Falhas • Quando ocorre uma falha, o conteúdo desses buffers pode perder-se, ou pelo menos pode não existir uma garantia de validade do seu conteúdo; • Assim os checkpoints registam os momentos em que o conteúdo dos buffers foi escrito nos discos, definindo-se um momento em que o transaction log e a BD estão sincronizados.

28. Arquitetura do Gerenciador de Recuperação • Log  recuperação de curta duração • Falha de transação • Recuperação de média e longa duração • Falha de sistema (BD + Log) • Falha de disco (Cópia de segurança + Log) Transações Gerenciador de Recuperação Escalonamento BD Cópia de segurança Log

29. Recuperação de Falha de Disco • O BD está danificado! • Uma falha deste tipo ocorre raramente, mas deve ser prevista • Necessita de uma cópia de segurança (backup) atualizada periodicamente • O BD deve ser restaurado • pela carga da cópia de segurança e • pelo uso do Log para refazer todas as operações feitas após a cópia

30. Tipos de Backup • Completo • Banco de Dados • Realiza o backup de todo o banco de dados • Arquivo de Log • Realiza o backup apenas do Log • Diferencial • Realiza o backup apenas da parte que foi modificada após o último backup

31. Recuperação usando Log • Arquivo onde ficam armazenadas todas as operações realizadas no BD • Cada vez que é executada uma operação sobre uma linha de uma tabela é criado uma entrada (ou registro) no Log • Exemplos de registros no Log: • [begin_Transaction, T] • [write, T, X, old, new] • [read, T, X] • [commit, T] • [abort, T]

32. Log • Armazenado na memória principal, em meio não-volátil e em meio estável • É um arquivo serial que guarda todas as modificações que foram realizadas no BD e quais transações realizaram quais modificações • Este arquivo é lido durante o processo de recuperação pois pode levar um BD ao seu último estado consistente antes da falha • Uma transação só é considerada executada quando todos os registros do Log destatransação estiverem armazenadas no banco de dados físico • Registros do Log devem ser armazenados no arquivo na ordem em que eles foramcriados (exemplo: antes que o registro <commit, Ti> seja armazenado no arquivo, todos osoutros registros desta transação já devem estar)

33. Recuperação de Falha de Transação • Deve ser executada pelo SGBD quando • uma transação que estava sendo executada é cancelada (explícita/implícitamente) • Recuperação • Os efeitos da transação em questão devem ser desfeitos • Para isso, deve-se varrer o arquivo de Log para identificar as operações já realizadas pela transação

34. Recuperação de Falha do Sistema • O SGBD parou de executar • Operações que estavam na memória volátil não foram armazenadas na memória física • Consequentemente • Todas as transações que estavam em execução no momento da falha devem ser desfeitas • Questão: • Como o SGBD sabe as transações que estavam em execução? Deverá varrer todo o Log?

35. Checkpoint • Ponto de controle • De tempos em tempos, o SGBD escreve no Log umregistro especial chamado checkpoint, que serve para registraras transações em execução • A execução de um checkpoint envolve: • Gravar fisicamente o conteúdo do BD da memória volátil no BD físico • Gravar fisicamente (meio estável) o conteúdo do Log • Gravar um registro de checkpoint no Log • Se não existe este registro, teríamos que investigar todo o arquivo de Log para recuperar o BD

36. Checkpoint • Quando ocorre uma falha de sistema • Todas as transações cujos registros <commit, Ti> estejam depois do checkpoint mais recente gravado no Log • Devem ser refeitas (REDO) • Todas as transações cujos registros <begin transaction, Ti> estejam no Log mas os registros <commit, Ti> ou <rollback, Ti> não estejam • Devem ser desfeitas (UNDO)

37. Tempo Checkpoint Falha do sistema T1 T2 • Quando ocorre uma falha, o SGBD verifica o último checkpoint • A recuperação de cada uma das transações ocorre das seguintes maneiras • T1 não é afetada • T2 e T4 já estão completadas mas não conseguiram ter suas atualizações gravadas no BD físico  Refazê-las • T3 e T5 ainda não tinham sido encerradas  Desfazê-las T3 T4 T5

38. Administradores e Utilizadores dos SGBD’s As categorias de utilizadores que intervêm num determinado sistema de BD, depende da natureza da BD, da sua dimensão e do tipo de organização em que é implementada. Porém e utilizando uma classificação genérica, os utilizadores podem ser classificados da seguinte forma: • utilizadores finais que actuam como operadores das aplicações que acedem à BD;

39. Administradores e Utilizadores dos SGBD’s • Utilizadores especializados possuem os conhecimentos teóricos e práticos que lhes permite interagir com o interface do sistema de forma a actualizar informação na BD, criar novas BD, etc.; • Programadores- técnicos com conhecimentos adequados para a criação de aplicações;

40. Administradores e Utilizadores dos SGBD’s • Administradores- responsáveis pela definição e implementação da política de informação da empresa. Por ex. :definir o tipo de informação, as permissões de acesso à informação.

41. Exercícios • Discuta os tipos de falhas que podem ocorrer a um BD. • O que é checkpoint? Qual a importância de gravar um registro de checkpoint no Log? • Explique o procedimento que deve ser feito para restaurar o BD no caso de uma falha do sistema.

42. Exercícios • Responda: (1) O que acontece depois da falha com cada transação e porque? (2) Qual o valor dos dados após o processo de recuperação? [início, T1] [read, T1, A] [read, T1, B] [início, T2] [read, T2, C] [write, T1, A, 3, 20] [commit, T1] [write, T2, C, 2, 40] [início, T3] [read, T3, B] [checkpoint] [write, T3, B, 10, 8] [commit, T3] [início, T4] [read, T4, A] [write, T2, D, 0, 25] [início, T5] [write, T4, A, 20, 15] [read, T5, A] [commit, T4] [write, T5, A, 15, 65] [read, T2, B] FALHA!