Aula 23 - Recuperação de falhas

Prévia do material em texto

Recuperação de falhas
Disciplina: Banco de Dados
Professor: Wandré Nunes de 
Pinho Veloso
2
Recuperação de falhas
• Falhas ocorrem por diversas causas, como erros 
nas transações (rollbacks) ou falhas no sistema
• Os conceitos fundamentais da recuperação no 
caso de certos tipos de falhas foram abordados
– Log do sistema
– Ponto de commit
• Este capítulo do livro cobre os procedimentos 
típicos e algoritmos para recuperação em caso 
de falhas
• Inclui recuperação em caso de falha catastrófica
3
Conceitos de Recuperação
• A recuperação de falhas significa retornar o BD a um 
estado consistente imediatamente anterior à ocorrência 
da falha
• A informação necessária para fazer isso é armazenada 
no log
• Estratégia típica:
– Se houver dano extensivo a uma grande parte do BD, devido a 
uma falha catastrófica, recuperar um backup e reconstruir o 
estado mais recente do banco, refazendo as operações 
armazenadas no log (que tem que ter sido backupeado também)
– Quando o BD não tiver sido danificado fisicamente, mas tiver se 
tornado inconsistente, reverter as modificações, desfazendo ou 
refazendo operações até alcançar um estado consistente
4
Conceitos de Recuperação
• Existem duas técnicas para recuperação 
de falhas não catastróficas (de 
transações)
– Atualização adiada ou postergada (deferred 
update)
– Atualização imediata (immediate update)
5
Conceitos de Recuperação
• Alteração adiada (deferred update)
– Não alteram fisicamente o disco até que a transação 
atinge o ponto de commit ou ponto de efetivação
– Enquanto não se chega ao ponto de commit, 
atualizações são mantidas em buffers locais; depois 
são registradas no log, e só então são feitas no BD
– Se houver falha, o BD não terá sido alterado, portanto 
não é necessário desfazer nada (NO-UNDO)
– Pode ser necessário refazer algo se a falha ocorrer 
após a gravação do log, porém antes da gravação no 
BD (REDO)
– Estratégia NO-UNDO/REDO
6
Conceitos de Recuperação
• Atualização imediata (immediate update)
– O BD pode ter sido atualizado por alguma operação de uma 
transação antes que esta chegue ao ponto de commit
– No entanto, essas operações são gravadas no log (usando 
force writing) antes que sejam aplicadas ao BD
– Se a transação falhar antes do ponto de commit, o log 
contém informação suficiente para desfazer o efeito dessas 
operações (UNDO)
– Pode também ser necessário refazer alguma operação, caso 
seu registro no log tenha sido gravado, mas seus efeitos não 
tenham sido materializados no BD (REDO)
– Estratégia UNDO/REDO
– Uma variação desta técnica em que todas as atualizações 
são gravadas no BD em disco antes do commit é chamada 
de UNDO/NO-REDO
7
Conceitos de Recuperação
• A recuperação é implementada com forte ligação ao SO, 
em particular com as funções de gerenciamento de 
memória virtual
– Paginação
– Cache
• O acesso a disco e o caching são feitos pelo próprio 
SGBD usando chamadas de baixo nível no SO
• Mas o SGBD mantém um controle de áreas de memória 
sob sua administração usadas para manter cópias de 
blocos do disco (cache do SGBD)
– Para cada bloco, existe um bit (dirty bit) que indica se o bloco 
deve ou não ser gravado em disco
8
Conceitos de Recuperação
• Existem duas estratégias quanto à operação de 
gravação de blocos no disco (flushing)
– Gravação em espaço adicional (shadowing)
• Mantém duas cópias separadas dos dados
– Before image (BFIM)
– After image (AFIM)
• Isso pode dispensar a existência do log para recuperação
– Gravação no próprio espaço anterior (in-place updating)
• Exige a existência do log
• O log precisa ser gravado antes que a BFIM seja sobrescrita 
pela AFIM: write-ahead logging
– O tipo de entrada no log é definido de acordo com a 
estratégia implementada (UNDO-type, REDO-type log 
entries)
9
Conceitos de Recuperação
• O cache do SGBD mantém também 
blocos de índices e de log
• Como o log é sequencial, pois sempre se 
acrescenta entradas ao final dele, o SGBD 
manterá em cache os últimos n blocos 
contendo dados do log
– Se for usado write-ahead logging, esses 
blocos precisam ser gravados (flushed) em 
disco antes que os blocos contendo dados 
sejam gravados
10
Conceitos de Recuperação
• Steal / no-steal
– No-steal: a página no cache que contém uma 
atualização não pode ser atualizada no disco até que 
a transação fique committed
– Steal: o protocolo permite que o buffer seja gravado 
antes do ponto de commit
• Force / No-force
– Force: o bloco de log é gravado imediatamente no 
disco quando a transação chega ao commit
– No-force: o log é mantido em memória até que seja 
necessário liberar espaço
11
Conceitos de Recuperação
• A técnica de atualização adiada exige um enfoque 
No-steal
• SGBD típicos usam um enfoque Steal/No-force
– Steal evita a necessidade de um grande buffer em memória para 
manter todas as páginas atualizadas esperando
– No-force ajuda a reduzir o custo de I/O, já que páginas na 
memória podem continuar recebendo atualizações antes do 
flush
– Portanto, a recuperação depende de uma estratégia de 
write-ahead logging que seja segura (UNDO e REDO)
• A BFIM não pode ser sobrescrita pela AFIM até que todos os 
registros de log (para UNDO) tenham sido gravados (force writing)
• O commit não pode ser concluído até que todos os registros de log 
(para REDO e UNDO) tenham sido gravados (force writing)
12
Conceitos de Recuperação
• Para facilitar a recuperação, o SGBD pode 
ter que manter listas contendo as 
transações ativas, as transações 
committed e as transações abortadas, de 
modo a poder interpretar o log 
corretamente
– Listas de transações committed e abortadas 
podem ser mantidas apenas desde o último 
checkpoint
13
Conceitos de Recuperação
• Check point: mais um tipo de entrada no log
• É escrito periodicamente no log no momento em 
que o SGBD salva em disco todos os blocos que 
tiverem sido modificados
• Consequentemente, todas as transações que 
tiverem seu registro [commit, T] gravado 
antes do check point não precisarão mais ser 
refeitas (REDO) em caso de falha, já que todas 
as atualizações já estarão registradas 
permanentemente
14
Conceitos de Recuperação
• Os check points podem ser realizados 
regularmente (a cada n minutos, ou a 
cada n transações committed)
• Em um check point
1. O processamento das transações é 
interrompido
2. Todos os buffers modificados são gravados 
no disco, incluindo listas de transações 
ativas, ponteiros para o log, etc.
3. A entrada de checkpoint é gravada no log, e 
o log é force-written para o disco
4. O processamento das transações é retomado
15
Conceitos de Recuperação
• Fuzzy checkpointing
– Reduz o atraso causado pelo 
checkpoint
– Permite que o processamento das 
transações continue logo após a 
gravação da entrada de checkpoint no 
log, mesmo antes que os buffers 
estejam todos gravados
– Mantém um apontador para o check 
point válido (o anterior) até que a 
gravação dos buffers seja completada
16
Técnicas de Recuperação
• Baseadas em atualização adiada ou 
postergada (deferred update)
• Baseadas em atualização imediata 
(immediate update)
17
Recuperação Baseada em
Atualização Adiada
• Como já visto, a ideia é postergar quaisquer 
atualizações sobre o BD até que a transação 
chegue ao ponto de commit
– Enfoque no Steal
– Write-ahead logging
– NO-UNDO/REDO
• Esta modalidade não é usada na prática, a 
menos que as transações sejam curtas e 
modifiquem poucos itens
– Caso contrário, existe a possibilidade de se ficar sem 
espaço em memória rapidamente
18
Recuperação Baseada em
Atualização Adiada
• Em um ambiente sem concorrência (monousuário)
– É apenas necessário terREDO
– Transações committed apenas precisam ser reexecutadas 
se a falha ocorrer antes do check point
– São usadas duas listas: uma para transações ativas, outra 
para transações committed desde o último checkpoint
– A lista de transações ativas apenas conterá uma 
transação
– O REDO é executado procurando operações 
write_item no log correspondentes a transações que 
constam da lista de transações committed desde o último 
checkpoint
• Obs.: o REDO é dito idempotente, pois pode ser aplicado várias 
vezes, tendo o mesmo efeito de uma única aplicação
• Obs2: a transação ativa não causa efeito algum
19
Exemplo de recuperação
Operações de leitura e gravação de três transações
20
21
Exemplo de recuperação
Operações antes da falha
22
Recuperação Baseada em
Atualização Adiada
• Em ambiente concorrente (multiusuário)
– Recuperação integrada ao controle de concorrência
– O REDO é executado da mesma forma que no 
ambiente não concorrente, porém garantindo a 
reexecução dos writes na mesma ordem em que 
forem encontrados no log
• Obs.: funciona considerando protocolo 2PL estrito, em outros 
casos podem ser necessárias outras providências
– Transações ativas são reexecutadas
• Este método nunca requer UNDO
23
Exemplo de recuperação em 
ambiente multiusuário
Exemplo de uma linha de tempo de recuperação para 
ilustrar o efeito do check point
24
Exemplo de recuperação em 
ambiente multiusuário
Exemplo de recuperação usando a atualização adiada com 
transações concorrentes
25
Log do sistema no ponto de falha
26
Recuperação Baseada em
Atualização Imediata
• Como já visto, a ideia é atualizar o BD 
“imediatamente”, sem esperar que a transação 
atinja o ponto de commit
– UNDO/NO-REDO
• Todas as atualizações são gravadas antes do commit
• NO-REDO em transações committed
• UNDO em transações abortadas
– UNDO/REDO
• O commit é permitido antes da gravação de todos os dados 
no BD
• REDO em transações committed, a partir do log
• É a técnica mais complexa
27
Recuperação Baseada em
Atualização Imediata
• Em ambiente sem concorrência (monousuário)
– Usar uma lista de transações committed desde o 
último check point e uma lista de transações ativas 
(no caso, com no máximo uma transação)
– Desfazer todas as operações write_item da 
transação ativa a partir do log (UNDO) >> ordem 
reversa
– Refazer todas as operações write_item das 
transações committed a partir do log, na ordem em 
que forem encontradas (REDO)
28
Recuperação Baseada em
Atualização Imediata
• Em ambiente concorrente (multiusuário)
– Novamente, depende do tipo de controle de concorrência
– No caso de escalonamento estrito, por exemplo, uma 
transação não pode ler ou gravar um item a menos que a 
transação que o tenha usado por último já tenha sido 
committed, ou abortada
– Neste caso, o procedimento seria o seguinte
• Usar uma lista de transações committed e uma lista de 
transações ativas
• Desfazer (UNDO) todas as operações write_item das 
transações ativas, na ordem reversa à encontrada no log
• Refazer (REDO) todas as operações write_item das 
transações committed, na ordem do log. Obs.: é possível 
analisar o log e apenas refazer a última gravação de cada item
29
Outras Técnicas
• Paginação shadow
– Vide seção 23.4
• Algoritmo ARIES
– Vide seção 23.5
30
Backups e Recuperação de
Falhas Catastróficas
• As técnicas exploradas até aqui referem-se a falhas em 
transações, essencialmente causadas por problemas 
lógicos, não catastróficas
• Para falhas catastróficas, o backup é o principal 
procedimento
– O backup do log deve ser feito a intervalos muito menores do 
que o backup completo do BD
– Pode-se ter muitos arquivos de log, quebrando a cada 
checkpoint
– No máximo serão perdidas as transações desde o último backup 
do log
– Na recriação do BD, deve-se recuperar o último backup 
completo e então refazer as operações registradas no log
• RAID e outras tecnologias voltadas a confiabilidade e 
tolerância a falhas podem evitar que falhas catastróficas 
(em um ou dois discos) forcem a recriação do BD a 
partir do backup
31
Bibliografia
• Capítulo 23: Elsmari Ramez; Navathe 
Shamkant B. Sistemas de Banco de 
Dados – Fundamentos e Aplicações. 6 ed. 
Pearson, São Paulo, 2011.