Je ne sais vraiment pas comment digérer le fait quune transaction est atomique. Si une transaction est un ensemble de « requêtes », comment sera-t-elle atomique. Je lie le mot «requêtes» à une requête SQL générale. Par conséquent, une transaction ne devient alors rien dautre quun ensemble de requêtes SQL exécutées en même temps. Mais le fait que chaque requête comporte plusieurs opérations, je ne comprends vraiment pas comment les requêtes précédemment exécutées (dans le même ensemble) reviennent si une erreur se produit dans une requête ultérieure. Quest-ce que joublie ici? Merci!
Réponse
TL; DR; Le journal des transactions contient toutes les informations nécessaires pour recréer ou annuler chaque transaction, selon quil contient ou non un enregistrement de validation pour cette transaction.
Dans les bases de données SQL, latomicité des transactions est implémentée le plus fréquemment en utilisant journalisation à écriture anticipée (ce qui signifie que les entrées du journal des transactions sont écrites avant que les tables et index réels ne soient mis à jour).
Requêtes au sens strict du terme, cest-à-dire SELECT les instructions et autres opérations de lecture qui ne changent pas létat de la base de données, ne sont pas journalisées car il ny a rien à valider ou à annuler, et en tant que tel le concept datomicité ne sapplique pas vraiment ici, au moins au niveau du SGBD. Lapplication consommant les résultats de la requête peut avoir besoin dappliquer latomicité en ignorant les résultats des requêtes précédentes si lune des requêtes suivantes échoue et provoque lannulation.
Lorsque les instructions DML (INSERT, UPDATE, DELETE, MERGE) et dautres instructions qui modifient létat de la base de données get exécutés, les modifications quils apportent sont dabord écrites dans le journal décriture anticipée (WAL). Si toutes les instructions réussissent et quune validation (explicite ou implicite) est émise, ce fait est également enregistré dans le WAL et le journal est conservé. Cela rend les changements durables. Ils peuvent être écrits dans la table réelle et les segments dindex à un moment ultérieur, lors dun point de contrôle ou dune relecture du journal.
Cependant, si lune des instructions échoue, il ny aurait pas denregistrement de validation dans le journal pour cette transaction, et le SGBD annulera les modifications de table et dindex effectuées jusquà présent en utilisant les enregistrements de journal précédents de cette transaction.
De même, si le processus SGBD tombe en panne ou si lalimentation est coupée, il ny aura pas un enregistrement de validation pour la transaction en cours, et les modifications de table ou dindex qui ont peut-être déjà été conservées seront annulées lors de la relecture du journal.
Commentaires
- Ceci nest ' t correct: " Requêtes au sens strict du mot, cest-à-dire instructions SELECT et autres opérations de lecture qui ne modifient pas létat de la base de données, ne sont pas journalisés car il ny a rien à valider ou à annuler " – selon les paramètres de votre base de données, même un SELECT peut démarrer un tr implicite ansaction. brentozar.com/archive/2018/02/…
- I ' je ne dis pas quils ' ne sont pas sous le contrôle des transactions, je ' je dis cela, puisquils sont ne change rien, ils ne sont pas journalisés.
Réponse
Une transaction est atomique lorsquelle est encapsulée comme ceci:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Dans ce cas, les deux mises à jour sur les deux tables séparées seront validées ensemble, ou elles seront annulées (échouer) ensemble. Latomicité signifie cest la plus petite unité dune transaction qui sera validée.
Cependant, si plus tard, vous essayez dexécuter une requête distincte en dehors de cette portée, ce serait une transaction distincte.
Si vous essayez quelque chose comme ceci:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; Et puis dans votre application, vous faites dautres types de travail, comme du code C #, puis revenez à la base de données plus tard et faites ceci:
UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Ensuite, la mise à jour précédente des utilisateurs et la mise à jour de vos messages suivante réussiront ou échoueront ensemble.
Cependant, dans la vraie vie, vous ne pouvez pas maintenir une transaction ouverte comme cela pendant une période prolongée parce que vous empêcherez dautres personnes de travailler dans la base de données. Cest pourquoi vous verrez souvent des conseils comme «Gardez votre transaction courte et agréable», ce qui signifie, entrez, faites votre travail et repartez. Ne maintenez pas explicitement les transactions ouvertes.
Commentaires
- Une transaction est toujours atomique, isn ' t it?
- Oui, mais selon les paramètres de votre base de données, vous pouvez avoir des transactions implicites activées – ce qui signifie que vous ' re obtenir un BEGIN TRAN même si vous ne ' que vous le demandez. Cela varie selon le fournisseur – par exemple, jentends quOracle utilise par défaut des transactions implicites, contrairement à SQL Server.Vous pourriez PENSER que vous ' nobtenez quune seule transaction si vous venez dun arrière-plan Oracle, alors que vous pourriez obtenir plusieurs transactions différentes dans SQL Server – chacune delles serait atomique.