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


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


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


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


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.


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;


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);


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)


É 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. [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.


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.


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;


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

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 - 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?

[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]

recuperação após falha

Documents