DBMS Distribuído - Falha e Compromisso

Um sistema de gerenciamento de banco de dados é suscetível a várias falhas. Neste capítulo, estudaremos os tipos de falha e os protocolos de confirmação. Em um sistema de banco de dados distribuído, as falhas podem ser amplamente categorizadas em falhas leves, falhas graves e falhas de rede.

Falha Suave

A falha suave é o tipo de falha que causa a perda da memória volátil do computador e não do armazenamento persistente. Aqui, as informações armazenadas no armazenamento não persistente, como memória principal, buffers, caches ou registros, são perdidas. Eles também são conhecidos como falha do sistema. Os vários tipos de falhas leves são os seguintes -

Falha do sistema operacional.
Falha de memória principal.
Falha na transação ou aborto.
Erro gerado pelo sistema, como estouro de número inteiro ou erro de divisão por zero.
Falha de software de suporte.
Falha de energia.

Falha Grave

Uma falha grave é o tipo de falha que causa perda de dados no armazenamento persistente ou não volátil como o disco. A falha do disco pode causar corrupção de dados em alguns blocos do disco ou falha do disco total. As causas de uma falha grave são -

Falha de energia.
Falhas na mídia.
Mau funcionamento de leitura e gravação.
Corrupção de informações no disco.
Leitura / gravação de falha na cabeça do disco.

A recuperação de falhas de disco pode ser curta, se houver um disco novo, formatado e pronto para usar na reserva. Caso contrário, a duração inclui o tempo que leva para obter um pedido de compra, comprar o disco e prepará-lo.

Falha na rede

As falhas de rede são predominantes em bancos de dados distribuídos ou de rede. Isso compreende os erros induzidos no sistema de banco de dados devido à natureza distribuída dos dados e à transferência de dados pela rede. As causas da falha de rede são as seguintes -

Falha no link de comunicação.
Congestionamento de rede.
Corrupção de informações durante a transferência.
Falhas do site.
Particionamento de rede.

Protocolos de Compromisso

Qualquer sistema de banco de dados deve garantir que as propriedades desejáveis de uma transação sejam mantidas mesmo após falhas. Se ocorrer uma falha durante a execução de uma transação, pode acontecer que todas as alterações causadas pela transação não sejam confirmadas. Isso torna o banco de dados inconsistente. Os protocolos de confirmação evitam esse cenário usando desfazer (rollback) ou refazer transação (rollforward).

Ponto de Compromisso

O ponto de tempo em que a decisão é tomada se deve confirmar ou abortar uma transação é conhecido como ponto de confirmação. A seguir estão as propriedades de um ponto de confirmação.

É um momento em que o banco de dados é consistente.
Neste ponto, as modificações trazidas pelo banco de dados podem ser percebidas pelas demais transações. Todas as transações podem ter uma visão consistente do banco de dados.
Neste ponto, todas as operações de transação foram executadas com sucesso e seus efeitos foram registrados no log de transações.
Nesse ponto, uma transação pode ser desfeita com segurança, se necessário.
Nesse ponto, uma transação libera todos os bloqueios mantidos por ela.

Desfazer transação

O processo de desfazer todas as alterações feitas em um banco de dados por uma transação é chamado de desfazer ou reversão da transação. Isso é aplicado principalmente em caso de falha leve.

Refazer transação

O processo de reaplicar as alterações feitas em um banco de dados por uma transação é chamado de refazer transação ou rollforward de transação. Isso é principalmente aplicado para recuperação de uma falha grave.

Log de transações

Um log de transações é um arquivo sequencial que rastreia as operações de transação nos itens do banco de dados. Como o registro é sequencial por natureza, ele é processado sequencialmente desde o início ou desde o final.

Objetivos de um log de transações -

Para apoiar protocolos de confirmação para confirmar ou suportar transações.
Para ajudar na recuperação do banco de dados após a falha.

Um log de transações geralmente é mantido no disco, para que não seja afetado por falhas leves. Além disso, o log é periodicamente feito backup em um armazenamento de arquivo como fita magnética para protegê-lo de falhas de disco também.

Listas em logs de transações

O log de transações mantém cinco tipos de listas, dependendo do status da transação. Essa lista ajuda o gerenciador de recuperação a verificar o status de uma transação. O status e as listas correspondentes são as seguintes -

Uma transação que possui um registro de início de transação e um registro de confirmação de transação é uma transação confirmada - mantida na lista de confirmação.
Uma transação que possui um registro de início de transação e um registro de falha de transação, mas não um registro de anulação de transação, é uma transação com falha - mantida na lista de falha.
Uma transação que possui um registro de início de transação e um registro de aborto de transação é uma transação abortada - mantida na lista de abortos.
Uma transação que possui um registro de início de transação e um registro de transação antes da confirmação é uma transação antes da confirmação, ou seja, uma transação onde todas as operações foram executadas, mas não confirmadas - mantidas na lista antes da confirmação.
Uma transação que possui um registro de início de transação, mas nenhum registro de pré-confirmação, confirmação, aborto ou falha, é uma transação ativa - mantida na lista ativa.

Atualização Imediata e Atualização Adiada

A atualização imediata e a atualização adiada são dois métodos de manutenção dos logs de transações.

Dentro immediate updatemodo, quando uma transação é executada, as atualizações feitas pela transação são gravadas diretamente no disco. Os valores antigos e os valores de atualização são gravados no log antes de gravar no banco de dados no disco. Na confirmação, as alterações feitas no disco se tornam permanentes. Na reversão, as alterações feitas pela transação no banco de dados são descartadas e os valores antigos são restaurados no banco de dados a partir dos valores antigos armazenados no log.

Dentro deferred updatemodo, quando uma transação é executada, as atualizações feitas no banco de dados pela transação são registradas no arquivo de log. Na confirmação, as mudanças no log são gravadas no disco. Na reversão, as alterações no log são descartadas e nenhuma alteração é aplicada ao banco de dados.