Вы находитесь на странице: 1из 55

Recuperao de Falhas em SGBDD

Aluno: Antnio Ezequiel de Mendona daem@cin.ufpe.br Click to editAna Carolina Brando Salgado Master subtitle style Orientadora: acs@cin.ufpe.br Centro de Informtica (CIn) Ps-Graduao em Cincia da Computao Universidade Federal de Pernambuco (UFPE)

Banco de Dados Distribudos e Mveis 2012.1

Recuperabilidade
A recuperao de transaes que falharam significa que o BD ser restaurado para o estado de consistncia mais recente, exatamente como antes do incio da transao que estava executando quando ocorreu da falha.

Banco de Dados Distribudos e Mveis 2012.1 22

Recuperabilidade
Duas situaes podem ser consideradas: 1) Falha catastrfica Restaura uma cpia anterior do Banco de Dados e reconstri um estado mais atual de acordo com as ultimas entradas de LOG armazenadas; 2) Falha no-catastrfica a estratgica reverter quaisquer mudanas que causaram inconsistncia desfazendo algumas operaes.

Banco de Dados Distribudos e Mveis 2012.1 33

Recuperabilidade
Conceitos de Recuperao O buffering de pginas de disco (blocos) do banco de dados no cache de memria principal do SGBD. O caching de dos blocos sobre o controle do SGBD, independente do sistema operacional.

Banco de Dados Distribudos e Mveis 2012.1 44

Recuperabilidade
Conceitos de Recuperao Um diretrio de cache usado para manter os itens que esto nos buffers. Uma tabela com as entradas: <nome do item, localizao do buffer > O Banco requisita aes para um mesmo item, verifica no diretrio, se o item esta na cache. Caso no, ento o item deve ser localizado no disco e copiado para dentro do cache, provoca a paginao.
Substituir o buffer - FIFO (first in, first out), DBMIN.
Banco de Dados Distribudos e Mveis 2012.1 55

Recuperabilidade
Conceitos de Recuperao

Associado com cada item no cache existe um bit sujo (Dirty Bit), que pode ser includo na entrada do diretrio, para indicar se o item foi ou no modificado. 0 - no foi modificado; 1 - modificado. Ao esvaziar o buffer, os dados com bit igual a 1 so gravados no disco. Bit preso-solto, caso a pgina esteja presa, 1;
Banco de Dados Distribudos e Mveis 2012.1 66

Recuperabilidade

Banco de Dados Distribudos e Mveis 2012.1 77

Recuperabilidade
Conceitos de Recuperao

Em geral o item antigo e chamado de before image (BFIM), e o novo valor obtido depois da modificao e chamado de after image (AFIM).

Banco de Dados Distribudos e Mveis 2012.1 88

Recuperabilidade
Conceitos de Recuperao Duas estratgias so usadas para um item de dado voltar para o disco: 1 In -place updating escreve o item de dado no mesmo espao, ou seja, sobrescreve o valor antigo do item no disco. Gravando no Log. 2 Shadowing escreve um novo item em uma diferente localizao no disco, mltiplas cpias do item de dado podem ser mantidas. Log no estritamente necessrio.
Banco de Dados Distribudos e Mveis 2012.1 99

Recuperabilidade
REDO/ UNDO

O Sistema deve manter informaes sobre as atualizaes do BD em separado (LOG). Estratgias Perda por falha: reconstruo (REDO) Backup (Log) ------------> estado consistente mais prximo da falha.

Banco de Dados Distribudos e Mveis 2012.1 1010

Recuperabilidade
REDO/ UNDO

Estratgias O BD tornou-se inconsistente: reverter mudanas (UNDO) Banco de dados inconsistente -------> Banco de dados consistente.

Banco de Dados Distribudos e Mveis 2012.1 1111

Recuperabilidade
Abordagem Adiantado em LOG

O mecanismo de recuperao deve garantir que a BFIM do item de dados seja registrada em uma entrada de LOG antes que a BFIM seja sobrescrita pela AFIM.

Banco de Dados Distribudos e Mveis 2012.1 1212

Recuperabilidade
Abordagem roubado(steal)/no roubado(no-steal) Especifica quando uma pgina do BD poder ser gravada em disco a partir do cache. Se uma pgina em cache atualizada por uma transao no puder ser gravada antes que a transao se efetive, ela ser chamada de abordagem no-roubada, caso contrrio chamada roubada. No-roubada dispensa Undo. Gerenciado de cache precisa de um frame buffer, o gerenciador de buffer substitui uma pgina existente, mas que a transao no foi confirmada.
Banco de Dados Distribudos e Mveis 2012.1 1313

Recuperabilidade
Abordagem forado(force)/no-forado(no-force)

Se todas as pginas atualizadas por uma transao forem imediatamente escritas no disco quando a transao se efetivar, ela ser chamada de abordagem forada, caso contrrio ser no-forada. REDO nunca ser necessria no forada. Os bancos usam roubada/no-forada.

Banco de Dados Distribudos e Mveis 2012.1 1414

Recuperabilidade
Vantagens roubada(steal)/no-forada(no-force)

Roubada Evita a necessidade de um espao buffer muito grande, para armazenar todas as pginas. No-forada Uma pgina atualizada de uma transao confirmada ainda pode estar no buffer quando outra transao precisar usar, eliminando os gastos E/S, para pginas muito atualizadas.
Banco de Dados Distribudos e Mveis 2012.1 1515

Recuperabilidade
Wal (logging write-ahead)

As entradas no Log precisam ser gravadas permanentemente no disco antes das mudanas serem aplicadas ao banco de dados. Fornece a atomicidade e durabilidade. Trabalha com UNDO e REDO

Banco de Dados Distribudos e Mveis 2012.1 1616

Recuperabilidade
No PostgreSQL esses logs so denominados WAL(Write Ahead Logs)e possuem por padro 16MB. Em um intervalo de tempo configurado ou atravs de comando SQL, as transaes que sofreram COMMIT so transferidas do WAL para o arquivo de dados e os logs so reciclados, essa operao conhecida comoCHECKPOINT.
1717

Banco de Dados Distribudos e Mveis 2012.1

Recuperabilidade
Para facilitar o processo de recuperao, o DBMS mantm uma lista para cada tipo transao:
1.

2. 3.

ativas aquelas que tenham comeado mas ainda no foram comitadas. transaes j comitadas. transaes abortadas.

Todas com seus respectivos checkpoints.

Banco de Dados Distribudos e Mveis 2012.1 1818

Recuperabilidade
Checkpoints no LOG de sistema

Um registro que escrito periodicamente dentro do LOG. O ponto em que o sistema grava no disco, todos os buffers do SGBD que tiverem sido modificados. Transaes que tiverem entradas [commit, T] no LOG, antes do [chekpoint], no necessitaro ter suas operaes WRITE refeitas, no caso de falha, pois todas as suas atualizaes foram registradas em disco durante o checkpoint.
Banco de Dados Distribudos e Mveis 2012.1 1919

Recuperabilidade
Checkpoints no LOG de sistema

Como o SGBD deve decidir o momento de submeter um checkpoint? Resp.: o momento de realizao de um checkpoint pode ser decidido por intervalo de tempo (n minutos) ou por nmero de transaes efetivadas desde o ltimo checkpoint.

Banco de Dados Distribudos e Mveis 2012.1 2020

Recuperabilidade
Checkpoints no LOG de sistema O que consiste a ao de checkpoint? submisso do

1 Suspender a execuo das transaes temporariamente; 2 Gravar no disco todos os buffers da memria principal que tenham sido alterados; 3 Escrever um registro de [checkpoint] no LOG e forar a gravao do LOG no disco; 4 Reassumir a execuo das transaes.
Banco de Dados Distribudos e Mveis 2012.1 2121

Recuperabilidade
Checkpoints no Log de sistema O passo 2 pode atrasar o processamento da transao por causa do passo 1. Para reduzir este atraso, uma tcnica chamada fuzzy checkpoint pode ser usada. Transaes continuem aps um registro de checkpoint ser gravado no LOG, sem esperar o passo 2 terminar. Ao termino do passo 2, a gravao do LOG feita no disco.
Banco de Dados Distribudos e Mveis 2012.1 2222

Recuperabilidade

Banco de Dados Distribudos e Mveis 2012.1 2323

Recuperabilidade
Rollback de Transao

Caso uma transao falhe durante uma alterao no BD, realizado um rollback. Os itens de dados que tenham sido mudados por uma transao devem ser retornados aos seus valores anteriores a modificao. Os registros no LOG do sistema so utilizadas para recuperar o valor antigo.

Banco de Dados Distribudos e Mveis 2012.1 2424

Recuperabilidade

Banco de Dados Distribudos e Mveis 2012.1 2525

Recuperabilidade
Rollback de Transao

Rollback em Cascata: Se uma transao T desfeita e uma transao S leu algum dado atualizado por T, S tambm tem que ser desfeita e assim por diante. Bloqueio em duas fases bsico. Complexo e demorado. Normalmente no utilizado pelos SGBDs.
Banco de Dados Distribudos e Mveis 2012.1 2626

Recuperabilidade
Rollback de Transao - Cascata
T 1 read( write( b) b) T 2 T 3 read( b) read( a) write( read( write( b) d) d)

read( Read( write( a) d) d) FALH A Temp o

T1 desfeita porque no alcanou o commit T2 desfeita porque leu o valor de b gravado por T1 T3 refeita Banco de Dados Distribudos e Mveis 2012.1 2727

Recuperabilidade
Duas tcnicas principais so utilizadas: Update adiado As atualizao no BD s sero feitas quando a transao atinja seu ponto commit. Antes do ponto commit, todas atualizaes das transaes so gravadas em uma copia local (buffer) e no LOG, depois gravada no disco. Caso a transao falhe antes de alcanar seu ponto commit, ela no ter afetado o estado do BD.

Banco de Dados Distribudos e Mveis 2012.1 2828

Recuperabilidade
Update Adiado O BD nunca atualizado no disco at que a transao seja efetivada, desta forma nunca ser necessria qualquer operao UNDO (desfazer). Existiro apenas entradas do tipo REDO no Log. Utilizamos o algoritmo de recuperao NOUNDO/REDO Operaes Idempotentes

Banco de Dados Distribudos e Mveis 2012.1 2929

Recuperabilidade
Por que s utiliza-se o REDO?
Resp.: Refazer (REDO) deve ser usado em situaes em que o sistema falhar depois que uma transao for efetivada, sendo que antes que todas as suas mudanas sejam registradas no disco. Nesse caso, as operaes da transao sero refeitas a partir das entradas do LOG.

Banco de Dados Distribudos e Mveis 2012.1 3030

Recuperabilidade
Update imediato
O BD atualizado pelas operaes de uma transao antes do seu ponto commit. As operaes so gravadas no Log em disco por escrita forada antes de serem aplicadas ao BD. Caso a transao falhe depois da gravao, algumas mudanas no BD devem ser realizadas. Uma coleo de buffers (DBMS cache) mantida. Entradas no Log UNDO(BFIm), utiliza o steal.

Undo e Redo necessrios.


Banco de Dados Distribudos e Mveis 2012.1 3131

Recuperabilidade
Shadow (Sombra)

A paginao Shadow considera que o BD e composto por um nmero de pginas de tamanho fixo (ou bloco de discos) para processo de recuperao. Um catlogo com n entradas construdo no qual a i-esima entrada aponta para a i-esima pagina do BD em disco. Se no for muito grande o catlogo ser mantido na memria principal.
Banco de Dados Distribudos e Mveis 2012.1 3232

Recuperabilidade
Shadow (Sombra)

Transao se inicia, o catlogo corrente cujas entradas apontam para os mais recentes ou correntes pginas em disco copiado em um shadow (sombra), o qual salvo no disco, enquanto o catlogo corrente usado pela transao. Durante a execuo da transao, o catlogo shadow nunca e modificado.
Banco de Dados Distribudos e Mveis 2012.1 3333

Recuperabilidade
Shadow (Sombra) A operao escrever_item for executada, uma nova cpia da pgina modificada do BD ser escrita, mas a cpia antiga dessa pgina no ser sobrescrita. Para recuperar basta livrar-se das pginas modificadas e descartar o catlogo corrente. Desvantagem que as pginas em atualizao mudam de localizao no disco, tornando difcil manter paginas juntas. Em caso de diretrio grande, temos overhead significativo.
Banco de Dados Distribudos e Mveis 2012.1 3434

Recuperabilidade
Catlogo corrente (depois de atualizar as 1 paginas 5,2) 2 3 4 5 6 Pgina 5 (velha) Pgina 1 Catlogo shadow (no atualizar) 1 2 3 4 5 6

Pgina 4 Pgina 2 Velha Pgina 3 Pgina 6 Pgina 2 Nova Pgina 5 Nova Banco de Dados Distribudos e Mveis 2012.1

3535

Recuperabilidade
O mtodo de recuperao ARIES Faz uso das abordagens roubada(steal)/noforada(no-force) para gravao e baseado em trs conceitos: 1) registro adiantado em Log; 2) repetio de histrico durante o refazer; 3) mudanas do Log durante o desfazer. Usado pela IBM.
Banco de Dados Distribudos e Mveis 2012.1 3636

Recuperabilidade
Recuperao em Falhas Catastrficas

O Banco de dados ser restaurado para o estado de consistncia mais recente, exatamente como antes do momento da falha. As tcnicas vistas se aplicam a falhas no catastrficas. Para manipular falhas catastrficas, como por exemplo quebras de disco, a principal tcnica usada nestes casos e a de backup do banco de dados.
Banco de Dados Distribudos e Mveis 2012.1 3737

Recuperabilidade
Recuperao em Falhas Catastrficas

Todo o banco de dados e seu Log so periodicamente copiados para um meio de armazenamento relativamente barato, como por exemplo, fitas magnticas.

Banco de Dados Distribudos e Mveis 2012.1 3838

Recuperabilidade
Falhas em sistemas de Banco de Dados

Fonte: IBM, universidade de Stanford. Banco de Dados Distribudos e Mveis 2012.1 3939

Recup. Distribuda
Caractersticas de Sistemas confiveis

O que preveno de falhas?


o processo que estabelece os mecanismos para evitar a ocorrncia.

O que deteco de falhas?


a capacidade de detectar erros.

O que Latncia de erro?


a diferena de tempo entre o incio de um evento e o momento em que seus efeitos tornam-se perceptveis.
Banco de Dados Distribudos e Mveis 2012.1 4040

Recup. Distribuda
Caractersticas de Sistemas confiveis

O que preveno de falhas?


o processo que estabelece os mecanismos para evitar a ocorrncia.

O que deteco de falhas?


a capacidade de detectar erros.

O que Latncia de erro?


a diferena de tempo entre o incio de um evento e o momento em que seus efeitos tornam-se perceptveis.
Banco de Dados Distribudos e Mveis 2012.1 4141

Recup. Distribuda
Viso Geral

Processo bastante complicado. Difcil determinar se um site est Parado. Site X envia uma mensagem para site Y, e no obtm resposta de Y, possveis causas?
A mensagem de X no foi entregue a Y (falha de comunicao). Site Y Parado. Y est rodando, mas a resposta no chegou a X.
Banco de Dados Distribudos e Mveis 2012.1 4242

Recup. Distribuda
Viso Geral Para manter a atomicidade de uma transao preciso uma mecanismo de recuperao em dois nveis. Gerenciamento de recuperao global ou coordenador e os gerenciadores de recuperao local (Logs). Coordenador segue o protocolo de confirmao em duas fases.

Banco de Dados Distribudos e Mveis 2012.1 4343

Recup. Distribuda
Viso Geral

Mensagens adicionais so necessrias. Problema da confirmao distribuda. Atualizao no pode ser confirmada, se ela altera dados em vrios sites, at ter certeza que as mudanas em cada site no ser perdida. Os dados do Log da alterao local em cada site precisa ter sido feita no disco.

Banco de Dados Distribudos e Mveis 2012.1 4444

Recup. Distribuda
Tipos de Falha Falhas de transaes Falhas de sites Falhas de mdia Falhas de comunicao

Banco de Dados Distribudos e Mveis 2012.1 4545

Recup. Distribuda
Transao distribuda de Dados Fases do protocolo de confirmao:
1.

2.

3.

4.

Cada site participante sinalizam ao coordenador que a transao local foi concluda. O coordenador envia uma mensagem de preparao para confirmao. Cada site que receber a mensagem forar a gravao do Log e as informaes de recuperao no Log. Os sites enviaro um sinal de Pronto para confirmao ou ok ao coordenador.
Banco de Dados Distribudos e Mveis 2012.1 4646

Recup. Distribuda
Transao distribuda de Dados Fases do protocolo de confirmao (continuao):
5.

6.

7.

Se a gravao forada em disco falhar, o participante(site) enviar um sinal de no estou pronto (no ok). Se o coordenador no receber uma mensagem em um certo tempo, assume no ok. Se todos participantes responderem ok e o voto do coordenador for ok, ento a transao ser bem sucedida, e ser enviado uma mensagem confirmao aos sites.
Banco de Dados Distribudos e Mveis 2012.1 4747

Recup. Distribuda
Transao distribuda de Dados Fases do protocolo de confirmao(C2F):
8.

9.

10. 11.

Com a gravao das informaes locais no Log foi bem sucedida, ento a recuperao poder ser efetuada. Se o coordenador ou algum dos participantes sinalizar como no ok, o coordenador enviar um mensagem de reverter (UNDO) - Global-abort a cada participante. Utilizando as informaes do Log, o UNDO realizado. Abort unilateral participante tem permisso de abortar.

Banco de Dados Distribudos e Mveis 2012.1 4848

Recup. Distribuda
Transao distribuda de Dados Fases do protocolo de confirmao(C2F):
12.

13.

O participante no pode mudar seu voto, aps ter efetuado. So usados Timers para controlar o tempo de espera entre os participantes e o coordenador.

Banco de Dados Distribudos e Mveis 2012.1 4949

Recup. Distribuda
Transao distribuda de Dados(C2F)
Sinal falhou pronto transao ok Cada site grava em disco SinalSinal Sinal transao ok pronto falhou

BD 1 BD 3

nodo 1 nodo 3 red e


Gravao falhou

nodo 2

BD 2
(coordenad or )

Sinal falhou pronto transao ok

Preparao de Cancel Confirma Confirmao ar o Banco de Dados Distribudos e Mveis 2012.1

nodo n

BD n

5050

Recup. Distribuda
Coordenador

Initi al Grava begin_commit no log wait


Si m

Participan te Initi al Grava begin_commit no log


N o

r prepa e
Vota abort

Gravar abort no log


Envia commit Glob abo al rt

consolid ar? Grava ready no log read y .. . 5151

Algu m no?

Grava abort no log commi t

Grava commit no log

Grava end_transatio n Banco de Dados Distribudos e Mveis 2012.1

Recup. Distribuda
Variao do C2F Duas variaes foram propostas para melhorar o C2F, com isso: 1. Reduzindo o nmero de mensagens transmitidas entre o coordenador e os participantes. 2. Reduzir o nmero de vezes que o log gravado. Chamados ao de consolidao presumida abortar presumida e

Banco de Dados Distribudos e Mveis 2012.1 5252

Recup. Distribuda
Protocolo de trmino e Recuperao para C2F Servem os intervalos de tempo limite para o coordenador e os processos participantes O mtodo de tratamento depende do sincronismo das falhas e dos tipos das falhas. O coordenador tem tempo limite para commit, wait(espera resposta dos participantes), abort. Os participantes tem tempo limite para initial(espera uma mensagem prepara), ready(espera uma deciso global).
Banco de Dados Distribudos e Mveis 2012.1 5353

Recup. Distribuda
Protocolo de consolidao C3F (trs fases) Semelhante ao protocolo C2F, com a adio do comando PRECOMMIT. O coordenador adiciona um espera ao PRECOMMIT. um protocolo em que todos os estados so sncronos dentro de uma nica transao de estado.

Banco de Dados Distribudos e Mveis 2012.1 5454

Bibliografia
Ramakrishnan, Raghu, Sistemas de Gerenciamento de banco de dados, McGrawHill, So Paulo, 2008. Ozsu, M. Tomer, principles of distributed database systems 3rd edition, Springer, London, 2011. Navate, Shamkant B., Sistemas de Banco de Dados, Pearson, So Paulo, 2010. IBM. Disponvel em: <http://www.ibm.com>. Acesso em: 20 Abril. 2012, 16:30:00.

Banco de Dados Distribudos e Mveis 2012.1 5555

Вам также может понравиться