Transações DBMS

Todo castor! Estamos expandindo ativamente nossa gama de cursos, por assim dizer, e agora temos o prazer de apresentar um novo: "DBMS relacional" . O curso foi criado por um dos principais professores do curso Administrador Linux - Alexey Tsykunov . Caso contrário, tudo será como sempre: utilitários e lições abertas , nas quais Alex compartilhará coisas diferentes que não estão incluídas no próprio curso.

Vamos lá!

Uma transação pode ser definida como um conjunto de tarefas, cujo cumprimento é um pré-requisito para a conclusão correta da transação. Uma única tarefa é o bloco indivisível mínimo de alteração de dados.

Aqui está um exemplo de uma transação simples. Suponha que um funcionário do banco transfira 500 rúpias da conta A para a conta B. Essa transação pequena e simples envolve várias tarefas de baixo nível.

Conta A

Open_Account(A) Old_Balance = A.balance New_Balance = Old_Balance - 500 A.balance = New_Balance Close_Account(A) 

Conta B

 Open_Account(B) Old_Balance = B.balance New_Balance = Old_Balance + 500 B.balance = New_Balance Close_Account(B) 

Propriedades ACID

Uma transação no sistema de banco de dados deve manter Atomicidade, Consistência, Isolamento e Durabilidade - ACID, para abreviar - para garantir a precisão, integridade e integridade dos dados:

• Atomicidade - essa propriedade mostra que uma transação deve ser considerada como uma unidade atômica, ou seja, todas as suas operações são executadas ou não uma única. Não deve haver estados no banco de dados em que a transação seja parcialmente concluída. Os estados devem ser definidos antes do início da transação ou após a conclusão / interrupção / falha da transação.
• Consistência - Esta propriedade indica que o banco de dados deve permanecer em um estado consistente após qualquer transação. Nenhuma transação deve ter um efeito negativo nos dados no banco de dados. Se o banco de dados estava em um estado consistente antes da transação ser concluída, ele deveria estar nele após sua conclusão.
• Isolamento - no sistema de banco de dados, em que várias transações são executadas simultaneamente e em paralelo, a propriedade de isolamento indica que cada transação será executada e executada como se fosse a única transação no sistema. Nenhuma transação deve afetar a existência de outras transações.
• Resiliência - essa propriedade indica que o banco de dados deve ser estável o suficiente para armazenar todas as atualizações mais recentes, mesmo se o sistema cometer um erro ou reiniciar. Se a transação levar a uma atualização do fragmento de dados no banco de dados, essas alterações deverão continuar sendo armazenadas no banco de dados. Se a transação for feita, mas o sistema travar antes de gravar dados no disco, os dados deverão ser atualizados imediatamente após a reinicialização do sistema.

Serialização

Quando várias transações são executadas pelo sistema operacional em um ambiente com vários programas, é provável que as instruções de uma transação sejam combinadas com as instruções de outra.

• Uma programação é uma execução cronológica de uma série de transações. Uma programação pode ter muitas transações, cada uma das quais consiste em várias instruções / tarefas.
• Uma programação sequencial é uma programação na qual as transações são organizadas para que cada uma das transações seja concluída por sua vez. Um planejamento é chamado seqüencial apenas devido a um padrão de execução consistente.

Em um ambiente multi-transacional, uma programação sequencial é considerada uma referência. A ordem de execução das instruções em uma transação não pode ser alterada, mas a execução das instruções de duas transações pode ser aleatória. A execução não é prejudicial quando duas transações são mutuamente independentes e funcionam em diferentes segmentos de dados; mas se eles usarem os mesmos dados, os resultados poderão ser diferentes, o que pode levar o banco de dados a um estado inconsistente.

Para resolver esse problema, permitimos a execução paralela do agendamento de transações, caso as transações sejam serializadas ou tenham alguma relação de equivalência.

Horários equivalentes

Planejamentos equivalentes podem ser dos seguintes tipos:

Equivalência do resultado

Se dois planejamentos após a execução produzirem o mesmo resultado, eles serão considerados equivalentes no resultado. Os resultados podem ser os mesmos para alguns valores e podem diferir para outro conjunto de valores. Portanto, essa equivalência geralmente não é considerada significativa.

Equivalência de apresentação

Duas agendas são consideradas equivalentes na apresentação se as transações em cada uma das agendas executarem ações semelhantes de maneira semelhante.

Por exemplo:

• Se T lê os dados originais em S1, também lê os dados originais em S2.
• Se T ler o valor escrito por J em S1, ele também lerá o valor escrito por J em S2.
• Se T terminar de escrever valores em S1, também terminará de escrever valores em S2.

Equivalência de conflito

Dois planejamentos entrarão em conflito se eles tiverem as seguintes propriedades:

• Eles pertencem a transações diferentes.
• Eles acessam os mesmos dados.
• Pelo menos um deles é a operação de gravação.

Dois planejamentos com várias transações com operações conflitantes são considerados equivalentes a um conflito apenas se:

• Ambos os agendamentos contêm o mesmo conjunto de transações.
• A ordem dos pares de operações conflitantes é suportada nos dois planejamentos.

Nota - Os agendamentos equivalentes na apresentação são serializáveis ​​na apresentação e os agendamentos equivalentes a conflitos são serializáveis ​​por conflito. Todos os agendamentos serializáveis ​​por conflito são serializáveis ​​por apresentação.

Status da transação

Uma transação em um banco de dados pode estar nos seguintes estados:

• Ativo (ativo) - nesse estado, a transação começa a ser executada. Este é o estado inicial de qualquer transação.
• Parcialmente confirmado - Quando uma transação conclui sua operação final, ela é considerada parcialmente perfeita.
• Falha - Uma transação é considerada falhada se uma das verificações executadas pelo sistema de recuperação de banco de dados falhar. Essa transação não pode continuar.
• Interrompido - se alguma verificação falhar e a transação entrar em estado de falha, o gerenciador de recuperação reverterá todas as operações de gravação no banco de dados para retorná-lo ao estado original antes do início da transação.
  As transações nesse estado são consideradas interrompidas. O módulo de recuperação de banco de dados pode selecionar uma das duas operações após a transação ser interrompida:
  
  
  • Reinicie a transação;
  • Cancelar transação.
• Perfeito - se a transação tiver concluído com êxito todas as operações, será considerada perfeita. Todos os seus efeitos são registrados permanentemente no sistema de banco de dados.

O FIM

Como sempre, estamos aguardando comentários, uma pergunta que pode ser feita aqui e em uma lição aberta com Alexei .