Estou realmente confuso sobre como digerir o fato de que uma transação é atômica. Se uma transação é um conjunto de “consultas”, como será atômica. Estou relacionando a palavra “consultas” a uma consulta SQL geral. Portanto, uma transação se torna nada mais que um conjunto de consultas SQL executadas ao mesmo tempo. Mas o fato de que cada consulta tem várias operações, realmente não estou entendendo como as consultas executadas anteriormente (no mesmo conjunto) são revertidas se ocorrer um erro em uma consulta posterior. O que estou perdendo aqui? Obrigado!
Resposta
TL; DR; O log de transações contém todas as informações necessárias para recriar ou desfazer cada transação, dependendo se ele contém um registro de confirmação para essa transação ou não.
Em bancos de dados SQL, a atomicidade da transação é implementada com mais frequência usando registro write-ahead (o que significa que as entradas do registro de transações são gravadas antes das tabelas e índices reais serem atualizados).
Consultas no sentido estrito da palavra, isto é, SELECT instruções e outras operações de leitura que não alteram o estado do banco de dados, não são registradas porque não há nada para confirmar ou reverter e, como tal, o conceito de atomicidade não se aplica realmente aqui, pelo menos no nível de DBMS. O aplicativo que consome os resultados da consulta pode precisar aplicar a atomicidade, descartando os resultados das consultas anteriores se uma das consultas subsequentes falhar e causar a reversão.
Quando as declarações DML (INSERT, UPDATE, DELETE, MERGE) e outras instruções que alteram o estado do banco de dados get executado, as alterações feitas são primeiro gravadas no log write-ahead (WAL). Se todas as instruções forem bem-sucedidas e um commit (explícito ou implícito) for emitido, esse fato também será registrado no WAL e o log será persistido. Isso torna as mudanças duráveis. Eles podem ser gravados na tabela real e nos segmentos de índice posteriormente, durante um ponto de verificação ou repetição do log.
No entanto, se uma das instruções falhar, não haverá nenhum registro de confirmação no log para esta transação, e o SGBD desfará as alterações de tabela e índice feitas até agora usando os registros de log anteriores dessa transação.
Da mesma forma, se o processo do SGBD travar ou a energia acabar, não haverá um registro de confirmação para a transação em andamento, e as alterações de tabela ou índice que podem já ter sido persistidas serão desfeitas durante a reprodução do log.
Comentários
- Isso não é ' t correto: " Consultas no sentido estrito da palavra, ou seja, instruções SELECT e outras operações de leitura que não alteram o estado do banco de dados, não são registrados porque não há nada para confirmar ou reverter " – dependendo das configurações do banco de dados, até mesmo um SELECT pode iniciar um tr implícito ansaction. brentozar.com/archive/2018/02/…
- I ' não estou dizendo que ' não estão sob o controle da transação, ' estou dizendo que, uma vez que estão não mudando nada, eles não são registrados.
Resposta
Uma transação é atômica quando é encapsulada como isto:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Nesse caso, ambas as atualizações nas duas tabelas separadas serão confirmadas juntas, ou serão revertidas (falharão) juntas. Atomicidade significa esta é a menor unidade de uma transação que será confirmada.
No entanto, se mais tarde você tentar executar uma consulta separada fora desse escopo, será uma transação separada.
Se você tentar algo assim:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; E então em seu aplicativo, você faz outros tipos de trabalho, como código C #, e depois volta ao banco de dados mais tarde e faça isso:
UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Então, tanto a atualização de Usuários anterior quanto a atualização de Postagens subsequentes terão êxito ou falharão juntas.
No entanto, na vida real, você não pode manter uma transação aberta como isso por um longo período de tempo porque você estará bloqueando outras pessoas de fazerem o trabalho no banco de dados. É por isso que você frequentemente verá conselhos como “Mantenha sua transação curta e agradável”, ou seja, entre, faça seu trabalho e saia. Não mantenha transações abertas explicitamente.
Comentários
- Uma transação é sempre atômica, isn ' é?
- Sim, mas dependendo das configurações do seu banco de dados, você pode ter as transações implícitas ativadas – ou seja, você ' re obter um BEGIN TRAN mesmo se você não ' não pedir. Isso varia de acordo com o fornecedor – por exemplo, ouvi que o Oracle padroniza para transações implícitas, enquanto o SQL Server não.Você pode ACHAR que ' está obtendo apenas uma transação, se tiver experiência em Oracle, quando pode estar recebendo várias transações diferentes no SQL Server – cada uma delas seria atômica.