DBMS - Recuperação de Dados

Crash Recovery

O DBMS é um sistema altamente complexo com centenas de transações sendo executadas a cada segundo. A durabilidade e robustez de um DBMS depende de sua arquitetura complexa e de seu hardware e software de sistema subjacentes. Se ele falhar ou travar em meio às transações, espera-se que o sistema siga algum tipo de algoritmo ou técnicas para recuperar os dados perdidos.

Classificação de Falha

Para ver onde o problema ocorreu, generalizamos uma falha em várias categorias, como segue -

Falha de transação

Uma transação deve ser abortada quando falha em sua execução ou quando atinge um ponto de onde não pode prosseguir. Isso é chamado de falha de transação, onde apenas algumas transações ou processos são prejudicados.

Os motivos para uma falha na transação podem ser -

  • Logical errors - Onde uma transação não pode ser concluída porque contém algum erro de código ou qualquer condição de erro interno.

  • System errors- Onde o próprio sistema de banco de dados encerra uma transação ativa porque o SGBD não é capaz de executá-la ou deve parar devido a alguma condição do sistema. Por exemplo, em caso de conflito ou indisponibilidade de recursos, o sistema aborta uma transação ativa.

Falha do sistema

Existem problemas - externos ao sistema - que podem fazer com que o sistema pare abruptamente e cause uma pane no sistema. Por exemplo, interrupções no fornecimento de energia podem causar a falha do hardware subjacente ou falha do software.

Os exemplos podem incluir erros do sistema operacional.

Falha de disco

Nos primeiros dias da evolução da tecnologia, era um problema comum quando as unidades de disco rígido ou de armazenamento costumavam falhar com frequência.

As falhas de disco incluem a formação de setores defeituosos, inacessibilidade do disco, travamento da cabeça do disco ou qualquer outra falha, que destrói todo ou parte do armazenamento do disco.

Estrutura de Armazenamento

Já descrevemos o sistema de armazenamento. Em resumo, a estrutura de armazenamento pode ser dividida em duas categorias -

  • Volatile storage- Como o nome sugere, um armazenamento volátil não pode sobreviver a travamentos do sistema. Dispositivos de armazenamento voláteis são colocados muito próximos à CPU; normalmente eles estão embutidos no próprio chipset. Por exemplo, a memória principal e a memória cache são exemplos de armazenamento volátil. Eles são rápidos, mas podem armazenar apenas uma pequena quantidade de informações.

  • Non-volatile storage- Essas memórias são feitas para sobreviver a falhas no sistema. Eles são enormes em capacidade de armazenamento de dados, mas mais lentos em acessibilidade. Os exemplos podem incluir discos rígidos, fitas magnéticas, memória flash e RAM não volátil (bateria com backup).

Recuperação e Atomicidade

Quando um sistema falha, ele pode ter várias transações sendo executadas e vários arquivos abertos para que eles modifiquem os itens de dados. As transações são feitas de várias operações, que são de natureza atômica. Mas de acordo com as propriedades ACID do SGBD, a atomicidade das transações como um todo deve ser mantida, ou seja, ou todas as operações são executadas ou nenhuma.

Quando um DBMS se recupera de uma falha, ele deve manter o seguinte -

  • Deve verificar os estados de todas as transações que estavam sendo executadas.

  • Uma transação pode estar no meio de alguma operação; o SGBD deve garantir a atomicidade da transação neste caso.

  • Ele deve verificar se a transação pode ser concluída agora ou se precisa ser revertida.

  • Nenhuma transação poderia deixar o DBMS em um estado inconsistente.

Existem dois tipos de técnicas, que podem ajudar um SGBD na recuperação, bem como na manutenção da atomicidade de uma transação -

  • Manter os logs de cada transação e gravá-los em algum armazenamento estável antes de realmente modificar o banco de dados.

  • Mantendo a paginação sombra, onde as alterações são feitas em uma memória volátil, e posteriormente, o banco de dados real é atualizado.

Recuperação baseada em log

Log é uma sequência de registros, que mantém os registros das ações realizadas por uma transação. É importante que os logs sejam gravados antes da modificação real e armazenados em uma mídia de armazenamento estável, à prova de falhas.

A recuperação baseada em log funciona da seguinte forma -

  • O arquivo de log é mantido em uma mídia de armazenamento estável.

  • Quando uma transação entra no sistema e inicia a execução, ele grava um log sobre ela.

<Tn, Start>

  • Quando a transação modifica um item X, ela grava os logs da seguinte forma -

<Tn, X, V1, V2>

Ele lê que T n mudou o valor de X, de V 1 para V 2 .

  • Quando a transação termina, ele registra -
<Tn, commit>

O banco de dados pode ser modificado usando duas abordagens -

  • Deferred database modification - Todos os logs são gravados no armazenamento estável e o banco de dados é atualizado quando uma transação é confirmada.

  • Immediate database modification- Cada log segue uma modificação real do banco de dados. Ou seja, o banco de dados é modificado imediatamente após cada operação.

Recuperação com transações simultâneas

Quando mais de uma transação está sendo executada em paralelo, os logs são intercalados. No momento da recuperação, seria difícil para o sistema de recuperação rastrear todos os logs e, em seguida, iniciar a recuperação. Para amenizar essa situação, a maioria dos DBMS modernos usa o conceito de 'pontos de verificação'.

Checkpoint

Manter e manter registros em tempo real e em ambiente real pode preencher todo o espaço de memória disponível no sistema. Com o passar do tempo, o arquivo de log pode ficar grande demais para ser manipulado. Checkpoint é um mecanismo onde todos os logs anteriores são removidos do sistema e armazenados permanentemente em um disco de armazenamento. Checkpoint declara um ponto antes do qual o DBMS estava em estado consistente e todas as transações foram confirmadas.

Recuperação

Quando um sistema com transações simultâneas trava e se recupera, ele se comporta da seguinte maneira -

  • O sistema de recuperação lê os logs de trás para frente, do fim ao último ponto de verificação.

  • Ele mantém duas listas, uma lista de desfazer e uma lista de refazer.

  • Se o sistema de recuperação vê um log com <T n , Start> e <T n , Commit> ou apenas <T n , Commit>, ele coloca a transação na lista de refazer.

  • Se o sistema de recuperação vê um log com <T n , Start>, mas nenhum log de confirmação ou aborto encontrado, ele coloca a transação na lista de desfazer.

Todas as transações na lista de desfazer são então desfeitas e seus logs são removidos. Todas as transações na lista de redo e seus logs anteriores são removidos e refeitos antes de salvar seus logs.