Recuperação após falha
description
Transcript of Recuperação após falha
RECUPERAÇÃO APÓS FALHA
Lílian Simão Oliveira
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
BD Consistente
BD Inconsistente
Tran
saçõ
es
Falha
Técnicas de Recuperação
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)
Observe
O planejamento e o processo de Back Up 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?
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
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 on the fly
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
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
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
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.
Recuperação/Tolerância a 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
Recuperação/Tolerância a Falhas
Os backups são cópias de segurança da BD, que são executados periodicamente e constituem um ponto de partida para a recuperação da BD após a ocorrência de uma falha, independentemente da sua gravidade;
Refletem uma situação passada, donde a reposição a partir de um backup implica perder todas as actualizações posteriores à realização do mesmo.
Recuperação/Tolerância a 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;
Recuperação/Tolerância a 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);
Recuperação/Tolerância a 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)
Recuperação/Tolerância a 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)
Recuperação/Tolerância a Falhas
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).
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:1. [begin_Transaction, T]2. [write, T, X, old, new]3. [read, T, X]4. [commit, T]5. [abort, T]
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 desta transação estiverem armazenadas no banco de dados físico
Registros do Log devem ser armazenados no arquivo na ordem em que eles foram criados (exemplo: antes que o registro <commit, Ti> seja armazenado no arquivo, todos os outros registros desta transação já devem estar)
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
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?
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
Falha de disco - o(s) disco(s) onde a BD está armazenada fica(m) inutilizado(s). É a falha considerada mais grave e que obriga à 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 - pode resultar de problemas de hardware ou software, não sendo possível garantir a validade dos dados. Implica repor a BD a partir do seu último estado de integridade.
Solução: Recuperar o mais recente estado consistente do BD que existia antes da falha
Refazer ou desfazer transações
Requisitos dos SGBDTipo de Falhas
Falha de transação - é a mais inofensiva e recupera-se recorrendo ao ficheiro transaction log e as before images da transacção que não foi bem sucedida.
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
Em qualquer processo de recuperação recorre-se ao rollback das transações efetuadas até ao momento em que os transaction log e os ficherios da base estão sincronizados, para se poderem desfazer todas as transacções decorridas desde então.
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.
Requisitos dos SGBDTipo de Falhas
Falha de discoÚltimo backuo
Tn
Tn+1
Tn+2Tn+3
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;
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.
Requisitos dos SGBDTipo de Falhas
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)
Escalonamento
BD
Gerenciador deRecuperação
Tran
saçõ
es
Cópia de segurança Log
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
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
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:1. [begin_Transaction, T]2. [write, T, X, old, new]3. [read, T, X]4. [commit, T]5. [abort, T]
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 desta transação estiverem armazenadas no banco de dados físico
Registros do Log devem ser armazenados no arquivo na ordem em que eles foram criados (exemplo: antes que o registro <commit, Ti> seja armazenado no arquivo, todos os outros registros desta transação já devem estar)
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
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?
Checkpoint
Ponto de controle De tempos em tempos, o SGBD escreve no Log
um registro especial chamado checkpoint, que serve para registrar as 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
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)
T1
T2
T3
T4
T5
Checkpoint Falha do sistemaTempo
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
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;
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;
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.
Administradores e Utilizadores dos SGBD’s
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.
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?
[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!
[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]