CIN – UFPE Hélder Lima e Silva - hmls

Recuperação após falhas

hélder manoel lima e silva

- hmls -

CIN – UFPE Hélder Lima e Silva - hmls

SISTEMAS DE GERENCIAMENTO DE

BANCO DE DADOS




- hmls -

1. system crash ▷ perda da memória principal

2. falha de mídia ▷ perda da memória secundária

3. erros em aplicativos ▷ erro lógico no aplicativo

4. 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



- hmls -

1. Impossibilidade de recuperar os dados

2. BD inconsistente

BACKUP

Undo/Redo



- hmls -

Transações e Recuperação transação: unidade de recuperação de um BD

a gravação explícita do buffer no disco chama-se force writing

MEMÓRIASECUNDÁRIA

BUFFER



- hmls -

UNDO/REDO



- hmls -

Gerenciamento de buffer estratégias de relocação: FIFO/LRUalternativa: 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 discoA 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 discoColoca no buffer escolhido e

Faz dirty = FALSE



- hmls -

Gerenciamento de buffer terminologiassteal policy

Permite ao gerenciador de buffer escrever no disco antes do commit da transação. Alternativa: NO-STEAL

force policyGarante 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/FORCEundo desnecessário e redo desnecessário para transações consolidadas (commited)

IMPLEMENTAÇÃO MAIS USADA: STEAL/NO-FORCEsteal 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 consolidada



- hmls -

Recursos para recuperação

backupfaz cópias periodicamente do BD

loggingguarda caminho do estado atual das transações e modificações no BD

checkpointpermite que atualizações ao banco se tornem permanentes.

gerenciador de recuperaçãopermite ao sistema restaurar o BD para um estado consistente



- hmls -

Recursos para recuperaçãoBACKUP fita magnética

LOGGING não é usado apenas para recovery (monitoramento de performance)pode conter:1. entrada de transaçõesidentificadortipo de entrada (start, insert, delete, update, commit)identificador do item de dado afetadoimagem antiga do item de dade afetadoimagem novainformações de manutenção do log2. checkpoints (o ponto de sincronização entre o BD e o log)



- hmls -

Recursos para recuperaçãoCHECKPOINT

Envolve as seguintes operações:1. Escrever todas as entradas do log de memória principal

para a secundária

2. Escreve os blocos modificados no buffer do BD para a memória secundária

3. Escreve uma entrada do tipo checkpoint no arquivo de log



- hmls -


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.



- hmls -


CHECKPOINT transações concorrentes falha

Refazer (REDO) as transações depois do checkpoint e desfazer todas as transações ativas no momento da falha.



- hmls -

UNDO/REDO



- hmls -

Técnicas de RecuperaçãoDependem 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



- hmls -

adiada (BD atualizado depois do commit)o antes do commit: atualizações em memória

principalo depois do commit: log discoo undo desnecessário

Estratégias de recuperação



- hmls -

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. 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 BD4. 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

recuperação adiada



- hmls -

imediata (BD atualizado antes do commit)o gravação no log antes do BDo undo/redo ou undo/no-redo

Estratégias de recuperação



- hmls -

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 no BD.

recuperação imediata



- hmls -

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

Vantagens1. Elimina OVERHEAD para manter o arquivo de log2. Recovery mais rápido3. Nem UNDO, nem REDO.

Desvantagens 1. fragmentação 2. Necessidade de garbage collection

Shadow paging



- hmls -

FIM



- hmls -

Documents

CIN – UFPE Hélder Lima e Silva - hmls