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
Falha
BD
Inconsistente
BD
Consistente
Técnicas de Recuperação
Conceitos Básicos

Transação



Recuperação


O SGBD é acionado automaticamente para resolver os tipos de
falhas esperados
Condição básica


Unidade de trabalho; Unidade de recuperação
As propriedades devem ser preservadas
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:
Quanto você está disposto a perder?


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....
Meios de Armazenamento

Volátil





Não-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
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
Recuperação/Tolerância a 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.
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)
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.
2.
3.
4.
5.
[begin_Transaction, T]
[write, T, X, old, new]
[read, T, X]
[commit, T]
[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



Falha do sistema


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)
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
Requisitos dos SGBD
Tipo de Falhas
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 SGBD
Tipo 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 SGBD
Tipo 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
Último backuo
Tn+3
Falha de disco
Requisitos dos SGBD
Tipo 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;
Requisitos dos SGBD
Tipo 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.
Arquitetura do Gerenciador de
Recuperação
Escalonamento
BD

Cópia de
segurança
Log  recuperação de curta duração


Gerenciador de
Recuperaçã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)
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
 Arquivo
de Log
 Realiza

o backup de todo o banco de dados
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.
2.
3.
4.
5.
[begin_Transaction, T]
[write, T, X, old, new]
[read, T, X]
[commit, T]
[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)
Tempo
Checkpoint
Falha do sistema
T1
T2
T3
T4
T5


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;
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;

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.
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?
[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!