bd ii – recup eração de falhas ii – recup eração de falhas professor: lui s felipe leite....
TRANSCRIPT
BD II – Recuperação de
Falhas
Professor: Luis Felipe Leite
Contato
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!