Técnicas de recuperação em Banco de Dados

Um banco de dados (sua abreviatura é BD, em inglês DB - database) é uma entidade na qual é possível armazenar dados de maneira estruturada e com a menor redundância possível. Estes dados devem poder ser utilizados por programas, e/ou por diferentes usuários. Assim, a noção básica de dados é acoplada geralmente a uma rede, a fim de reunir conjuntamente estas informações. Fala-se, geralmente, de sistema de informação para designar toda a estrutura que reúne os meios organizados para poder compartilhar dados. Um BD permite colocar dados à disposição de usuários para uma consulta, uma introdução ou uma atualização. Um BD pode ser local, utilizável em uma máquina por um usuário, ou repartido, significa que as informações são armazenadas em máquinas distantes e acessíveis por rede. Mas, o que fazer quando os dados do BD sofrem alguma alteração indesejada? Quais procedimentos podemos tomar para recuperação em caso de falhas?

ALGORITMOS DE RECUPERAÇÃO

A recuperação de falhas existe para garantir as propriedades de atomicidade e durabilidade de transações. O sistema de recuperação(restauração) de falhas é responsável pela restauração do banco de dados para um estado – o que havia antes da ocorrência de uma falha. Os tipos de falhas tratáveis por um sistema de recuperação de falhas:

• Falha de transação → SGBD entra em ação;
• Erro lógico: a transação não pode mais continuar devido a alguma condição adversa interna;
• Erro do sistema: uma transação não pode mais continuar porque o sistema entrou num estado inadequado.

• Queda de sistema: perda de conteúdo volátil → continua-se com a base em meio não volátil;
• Falha de disco: perda parcial ou total do conteúdo não volátil:  sistemas de backup.

Os algoritmos de recuperação de falhas podem ser de dois tipos:

• Ações tomadas durante o processamento normal da transação a fim de garantir informações suficientes para permitir a recuperação de falhas;
• Ações tomadas em seguida à falha, recuperando o conteúdo do banco de dados para um estado que assegure sua consistência e a atomicidade e durabilidade das transações.

Vamos então conhecer o primeiro tipo:

Modificações Adiadas do BD

Também chamadas de NO-UNDO/REDO. Nesta técnica, somente o valor novo do item de dado que sofreu alteração é necessário ser guardado no registro de log, pois:

• Somente escalonamentos seriais estão sendo considerados;
• As escritas são realizadas após a efetivação parcial da transação;
• No caso de falhas:
• Antes das escritas no BD: os registros no log serão ignorados (o valor antigo do item de dado permanecerá).
• Após as escritas no BD: executa-se operações de REDO.

Exemplo:

Alterações feitas no BD:

Procedimento de recuperação em caso de falhas, que resultem em perda de informação no armazenamento volátil:

• REDO(Ti): Refazer Ti → define o valor de todos os itens de dados atualizados pela transação Ti para os novos valores (operação idempotente);
• Uma transação Ti deverá ser refeita, se e somente se, o sistema de recuperação encontrar os registros  <Ti, start> e <Ti, commit> no log.

                                         

Ações para o exemplo anterior:

• Nenhuma ação REDO é necessária;
• É necessário realizar REDO(T0), uma vez que há um <T0 commit> registrado;
• Realizar REDO(T0) seguido de REDO(T1), uma vez que <T0 commit> e <T1 commit> estão presentes no log.

Vamos conhecer agora o segundo tipo:

Modificações Imediatas do BD

Também chamadas de UNDO e NO-REDO. Esta técnica permite que as modificações no banco de dados sejam realizadas enquanto as transações ainda estão num estado ativo. As escritas emitidas por transações ativas são chamadas de modificações não-efetivadas. Neste esquema de modificação de BD, o log deverá armazenar o valor antigo e o valor novo oriundos das operações de write.

Execução de uma transação:

• Um registro <Ti, start> antes da transação Ti iniciar sua execução;
• Toda operação write(X) de Ti é precedida pela escrita de um novo registro no log;
• Quando Ti é parcialmente efetivada, um registro <Ti, commit> deve ser escrito no log.

Exemplo:

Alterações no BD:

                                

Procedimentos de recuperação em caso de falhas, que resultem em perda de informação no armazenamento volátil:

• UNDO(Ti): Desfazer Ti → retorna aos valores antigos todos os itens de dados atualizados pela transação Ti;
• REDO(Ti): Refazer Ti → ajusta os valores de todos os itens de dados atualizados pela transação Ti para os novos valores.

Após a falha, o sistema de recuperação consulta o log para determinar quais transação precisam ser desfeitas e quais precisam ser refeitas:

• A transação Ti tem que ser desfeita se o log contiver o registro <Ti start>, mas não possuir o registro <Ti commit>;
• A transação Ti tem que ser refeita se o log contiver tanto o registro <Ti start> quanto o registro <Ti commit>.

Ações para o exemplo anterior:

• UNDO (T0): B é restaurado para 2000 e A para 1000;
• UNDO (T1) e REDO (T0): C é restaurado para 700, e então, A e B retornam aos valores 950 e 2050, respectivamente.
• REDO (T0) and REDO (T1): Os valores de A, B e C na conta, após esses procedimentos, são 950, 2050 e 600, respectivamente.

REUNINDO A INFORMAÇÃO

O primeiro processo exposto (com REDO e NO-UNDO) vai adiando as gravações no Banco de Dados (BD) até que haja um commit com sucesso. Ou seja, só grava as alterações após o commit. Para refazer (REDO), uma entrada no log para gravação deve incluir o novo valor do item gravado. Todas as operações de escrita (write_item) das transações confirmadas devem ser refeitas, a partir do log na ordem em que foram gravadas, utilizando o procedimento REDO. As transações que estavam ativas e não chegaram ao commit são efetivamente canceladas e devem ser submetidas novamente.

No segundo processo (com UNDO e NO-REDO), assim que você realiza WRITE, os dados são escritos no BD sem a necessidade de um commit parcial. Ou seja, os dados são gravados antes do commit. Quando ocorre um erro na gravação, o BD realiza UNDO em todos os WRITE efetuados após um commit com sucesso. Não há necessidade de refazer operações se a técnica de recuperação garantir que todas as atualizações de uma transação sejam registradas no banco de dados em disco antes do commit da transação.

Por,

Kaio Oliveira - Integrante do PET Computação