Recuperação e Atomicidade de transações
Um banco de dados controla todas as ações feitas em seus dados como uma transação de banco de dados. Acontece que estas transações podem ter problemas em seu processamento e como é que o SGBD vai garantir que as transações já realizadas não sejam perdidas em caso de problemas. Explicar o que acontece e como sair desta situação é o nosso objetivo.
E sempre que acontece uma situação destas, dados podem ser perdidos e uma das principais funções de um banco de dados é garantir a recuperação causada por uma falha e restaurar a consistência e integridade do banco de dados.
Atomicidade
Como já foi visto, representa a indivisibilidade de uma transação.
Classificação de falhas
As falhas podem ser classificadas em duas modalidades:
- Falhas com perdas de informação.
- Falhas sem perda de informação.
Para que o sistema possa propor algoritmos que assegurem a consistência, integridade e atomicidade após cada falha, precisaram primeiro identificar os tipos de falhas possíveis e dividir o procedimento de recuperação em duas partes.
- Ações a serem tomadas durante o processamento normal da transação com o objetivo de assegurar que tenhamos informações suficientes para a recuperação em caso de falha.
- Ações a serem tomadas após a falha para assegurar a consistência do banco de dados e a atomicidade da transação.
Modelo de transação
Se estiver consistente quando uma transação iniciou, o banco de dados precisa ser consistente quando a transação terminar com sucesso.
Entretanto, durante a execução de uma transação, pode ser necessário temporariamente permitir esta inconsistência.
Consistência e Atomicidade
Cada transação precisa ser um programa que preserve a consistência do banco de dados. Todas as operações associadas a uma transação precisam ser executadas até o final, ou nenhuma deve ser executada.
Uma transação nem sempre pode completar sua execução com sucesso, quando isto acontece dizemos que ela foi abortada.
A fim de garantir a atomicidade, uma transação abortada não pode ter efeito no estado do banco de dados.
Assim o banco de dados precisa ser restaurado ao estado anterior ao início da transação que foi abortada. Este procedimento de desfazer o que foi iniciado recebe o nome de rollback.
Uma transação completada com sucesso é chamada de compromissada ou comitada (commited).
Estado de transação
Uma transação possui o seguinte modelo abstrato:
- Ativo – o estado inicial.
- Parcialmente compromissado – depois que a última instrução foi executada.
- Falhado – depois da descoberta de que uma execução normal não pode mais prosseguir.
- Abortado – depois que a transação foi desfeita e o banco de dados foi restaurado ao seu estado anterior ao início da transação.
- Compromissado – depois de a transação ser completada com sucesso.
Uma transação entra no estado falhado depois de ser determinado que a transação não possa mais prosseguir com sua execução normal, então ela precisa ser desfeita, a transação entra no estado abortado, nesse ponto o sistema tem duas opções:
- Reiniciar a transação – uma transação reiniciada é considerada uma nova transação. Apenas quando houve um erro de hardware ou software operacional (não de lógica).
- Matar a transação – ocorre quando o erro foi de lógica interna, necessitando rever a programação do programa.
Recuperação baseada em Log
A fim de garantir a atomicidade, o sistema de banco de dados, armazena um espelho da transação que será realizada, descrevendo as modificações envolvidas. Este modelo é chamado de log do banco de dados.
Nenhum comentário:
Postar um comentário