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