Décrire les transactions
Une transaction est une ou plusieurs instructions T-SQL qui sont traitées comme une unité. Si une transaction unique échoue, toutes les instructions échouent. Si une transaction réussit, vous savez que toutes les déclarations de modification de données de la transaction ont réussi et ont été enregistrées dans la base de données.
Les transactions garantissent que toutes les instructions d’une transaction réussissent ou échouent. Aucune exécution partielle n’est autorisée. Les transactions encapsulent des opérations qui doivent se produire logiquement ensemble, telles que plusieurs entrées dans des tables associées qui font partie d’une seule opération.
Considérez une entreprise qui stocke les achats dans une table Sales.Order et les paiements dans une table Sales.Payment . Lorsque quelqu’un achète quelque chose, les deux tables doivent être mises à jour. Si cette opération est implémentée sans transactions et qu’une erreur se produit lorsque le paiement est écrit dans la base de données, l’insertion Sales.Order est toujours validée, laissant la table de paiement sans entrée.
Lorsque cette opération est implémentée avec des transactions, les deux entrées sont effectuées ou aucune entrée n’est effectuée. En cas d’erreur lors de l’écriture du paiement dans la table, l’insertion de la commande est également annulée. Cela signifie que la base de données est toujours dans un état cohérent.
Il convient de noter que cela fait référence à des erreurs graves, telles que des erreurs matérielles ou réseau. Les erreurs dans les instructions SQL entraînent uniquement la restauration de la transaction dans certaines circonstances et il est important de passer en revue les unités suivantes de ce module pour comprendre pleinement les implications de l’utilisation des transactions.
Il existe différents types de transactions :
Transactions explicites
Les mots clés BEGIN TRANSACTION et COMMIT ou ROLLBACK démarrent et terminent chaque lot d’instructions. Cela vous permet de spécifier les instructions qui doivent être validées ou restaurées ensemble.
Transactions implicites
Une transaction est démarrée lorsque la transaction précédente est terminée. Chaque transaction est explicitement terminée avec une instruction COMMIT ou ROLLBACK.
Caractéristiques ACID
Les systèmes OLTP (traitement transactionnel en ligne) requièrent que les transactions répondent aux caractéristiques « ACID » :
- Atomicité : chaque transaction est traitée comme une unité unique, qui réussit complètement ou échoue complètement. Par exemple, une transaction qui implique le débit de fonds d’un compte et le crédit du même montant sur un autre compte doit effectuer les deux actions. Si une des deux actions ne peut pas être effectuée, l’autre action doit échouer.
- Cohérence : les transactions peuvent uniquement prendre les données de la base de données d’un état valide à un autre. Pour continuer avec l’exemple de débit et de crédit ci-dessus, l’état terminé de la transaction doit refléter le transfert de fonds d’un compte à l’autre.
- Isolation : les transactions simultanées ne peuvent pas interférer entre elles et doivent entraîner un état de base de données cohérent. Par exemple, alors que la transaction pour transférer des fonds d’un compte à un autre est en cours, une autre transaction qui contrôle le solde de ces comptes doit retourner des résultats cohérents : la transaction de vérification de solde ne peut pas récupérer une valeur pour un compte qui reflète le solde avant le transfert et une valeur pour l’autre compte qui reflète le solde après le transfert.
- Durabilité : lorsqu’une transaction a été validée, elle reste validée. Une fois la transaction de transfert de compte terminée, les soldes de compte modifiés sont conservés de sorte que même si le système de base de données devait être désactivé, la transaction validée serait reflétée lors de sa réactivation.