BD II – Recup eração de Falhas II – Recup eração de Falhas Professor: Lui s Felipe Leite....

Preview:

Citation preview

BD II – Recuperação de

Falhas

Professor: Luis Felipe Leite

Contato

luisleite@recife.ifpe.edu.brprofessorluisleite.wordpress.com

Ciclo de três aulas

Processamento de transações.

Controle de Concorrência.

Recuperação de Falhas.

Mecanismos de Recuperação de falhas em Banco de Dados

Visa recuperar o banco de dados para o seu último estado consistente antes de uma falha.

Preservar o famoso ACID.

Gerenciamento de Recuperação

A ideia principal é garantir tanto atomicidade quanto durabilidade.

Imaginem que cinco transações estão sendo processadas concorrentemente.

Três dessas transações terminam corretamente, duas dão crash.● Nesse caso garantir tanto Atomicidade, quanto

durabilidade pode ser complexo.

Gerenciamento de Recuperação

As transaçõesT1, T2 e T3 devempermanecer no banco,sendo garantida suadurabilidade

Já T4 e T5, devemser desfeitas.

Por fim é necessário garantir a atomicidade de todas elas.

Tipos de falhas

As falhas podem ser tanto físicas como de sistema.

Exemplo de falhas físicas:● Falha de disco;● Incêndio no hardware;● Catástrofe;● Quebra por n motivos.

Tipos de falhas

Exemplo de falhas de sistema:● Um erro de transação;● Problema no próprio sistema do computador e

servidor;● Erros variados no sistema ou na transação;● Imposição do controle de concorrência

(resolver um deadlock por exemplo).

Soluções para falhas mais comuns

Quando o problema é uma falha de disco, sistema ou até mesmo uma catástrofe, a solução é relativamente mais fácil.

O uso de replicação dos dados é largamente utilizado por todas as instituições e empresas no mundo.

O famoso Backup.

O uso de Raid auxilia no processo de backup e de segurança dos dados.

Mas e se...

Soluções para falhas mais comuns

O uso da cloud é uma boa opção.

Ainda assim existem alguns problemas...

Uso de Cache

A lentidão de alguns discos pode ser um problema grave para banco de dados.

A medida que várias gravações tem de ser processadas, existe a possibilidade de latências acontecerem e atrasar as transações.

É criada uma falsa ideia que a gravação está sendo feita no disco.

Uso de Cache

Enquanto as gravações são feitas, o banco de dados conversa com o S.O e começa a colocar as transações na memória.

Inclusive as que já foram comitadas.

A questão é que se der problema, esses dados vão estar na memória e não no disco. Como garantir durabilidade?

Uso de Cache

Primeiro: como saber o que foi ou não mexido?

Bit sujo● 1 → Alterada.● 0 → Não alterada (não precisa gravar).

Bit preso e solto● 1 → Página não pode ser gravada. (falta de memória

por exemplo).● 0 → Página pode ser gravada.

Uso de Cache – Shadow X In-place

Métodos de atualização/gravação

Shadow:● O item original nunca será modificado. Estará sempre criando

várias sombras do original. ● Este método tem todo o histórico de tudo que aconteceu.● Você pode voltar para onde quiser.

In-place:● A gravação sobrescreve o item anterior.● Se o item anterior é sobrescrito e é necessário um meio de

desfazer coisas, é preciso ter formas de gravar o que foi feito. (Logs).

Logs

Faz o registro em sequência das operações de transação efetuadas no banco de dados.

É rápido de gravar.

Serve para:● Auditoria;● Recuperar o sistema de falhas;● Refazer transações;● Desfazer ações de uma transação abortada.

Ele também é mantido em disco.

Protocolo Write Ahead Logging (WAL)

Este protocolo efetuas duas coisas importantes.

O protocolo será responsável por gravar o registro de operação no log antes que a modificação do item seja gravada em disco, garantindo dessa forma, atomicidade.Caso algo tenha que ser refeito ou desfeito, está no log, pois foi gravado antes.

Ele também é responsável por gravar todas as operações de uma transação no disco de log antes do commit, garantindo durabilidade.Tem que gravar no log antes de dar commit.O sistema pede commit, depois que for tudo gravado no log, o sistema é liberado para fazer commit.

Registros de log

[start_transaction, T][write_item, T, X, valor_antigo, novo_valor][read_item, T, X][commit, T][abort, T][checkpoint]

Checkpoint

Entrada no log gravada periodicamente.

É a gravação de todos os dados do buffer no disco.

Checkpoint

T1 não precisaser refeito porqueestá gravado no disco.T3 terá que ser refeito, mas sóa partir docheckpoint.T4 e T5 serão desfeitas.T2 será refeita pois nãoexistia antes do checkpoint.

Checkpoint Fuzzy

O checkpoint é feito durante as transações.

Usa [begin_checkpoint]. O checkpoint só vale do [begin_checkpoint] para trás.

Ao final, usa [end_checkpoint] a ser gravado no log e manter o checkpoint.

Até próxima aula!

Recommended