Transactions SGBD

Tout castor! Nous élargissons activement notre gamme de cours, pour ainsi dire, et nous sommes maintenant heureux d'en présenter un nouveau: «SGBD relationnel» . Le cours a été créé par l'un des principaux professeurs du cours Administrateur Linux - Alexey Tsykunov . Sinon, tout sera comme d'habitude: les utilitaires et les leçons ouvertes , dans lesquelles Alex partagera différentes choses qui ne sont pas incluses dans le cours lui-même.

C'est parti!

Une transaction peut être définie comme un ensemble de tâches dont la réalisation est une condition préalable à la bonne exécution de la transaction. Une tâche unique est le bloc minimal indivisible de modification des données.

Voici un exemple de transaction simple. Supposons qu'un employé de banque transfère 500 roupies du compte A au compte B. Cette petite et simple transaction implique plusieurs tâches de bas niveau.

Compte A

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

Compte B

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

Propriétés ACID

Une transaction dans un système de base de données doit préserver l'atomicité, la cohérence, l'isolement et la durabilité - ACID pour faire court - pour garantir l'exactitude, l'exhaustivité et l'intégrité des données:

• Atomicité - cette propriété montre qu'une transaction doit être considérée comme une unité atomique, c'est-à-dire que toutes ses opérations sont effectuées ou pas une seule. Il ne doit y avoir aucun état dans la base de données dans lequel la transaction est partiellement terminée. Les états doivent être définis soit avant le début de la transaction, soit après l'achèvement / l'interruption / l'échec de la transaction.
• Cohérence - Cette propriété indique que la base de données doit rester dans un état cohérent après toute transaction. Aucune transaction ne devrait avoir un effet négatif sur les données de la base de données. Si la base de données était dans un état cohérent avant la fin de la transaction, elle devrait y figurer après son achèvement.
• Isolation - dans le système de base de données, où plusieurs transactions sont effectuées simultanément et en parallèle, la propriété d'isolement indique que chaque transaction sera exécutée et exécutée comme s'il s'agissait de la seule transaction du système. Aucune transaction ne devrait affecter l'existence d'autres transactions.
• Résilience - cette propriété indique que la base de données doit être suffisamment stable pour stocker toutes les dernières mises à jour, même si le système fait une erreur ou redémarre. Si la transaction entraîne une mise à jour du fragment de données dans la base de données, ces modifications doivent continuer à être stockées dans la base de données. Si la transaction est effectuée, mais que le système se bloque avant d'écrire des données sur le disque, les données doivent être mises à jour immédiatement après le redémarrage du système.

Sérialisation

Lorsque plusieurs transactions sont effectuées par le système d'exploitation dans un environnement multi-programme, il est probable que les instructions d'une transaction soient mélangées avec les instructions d'une autre.

• Un calendrier est une exécution chronologique d'une série de transactions. Un programme peut comporter de nombreuses transactions, chacune consistant en plusieurs instructions / tâches.
• Un calendrier séquentiel est un calendrier dans lequel les transactions sont organisées de manière à ce que chacune des transactions soit effectuée à son tour. Un programme est appelé séquentiel simplement en raison d'un modèle d'exécution cohérent.

Dans un environnement multi-transactionnel, un calendrier séquentiel est considéré comme une référence. L'ordre d'exécution des instructions dans une transaction ne peut pas être modifié, mais l'exécution des instructions de deux transactions peut être aléatoire. L'exécution n'est pas nuisible lorsque deux transactions sont mutuellement indépendantes et fonctionnent sur des segments de données différents; mais s'ils utilisent les mêmes données, les résultats peuvent différer, ce qui peut conduire la base de données à un état incohérent.

Pour résoudre ce problème, nous autorisons l'exécution parallèle du calendrier des transactions dans le cas où les transactions sont sérialisées ou ont une relation d'équivalence.

Horaires équivalents

Les horaires équivalents peuvent être des types suivants:

Équivalence du résultat

Si deux planifications après l'exécution produisent le même résultat, elles sont considérées comme équivalentes en résultat. Les résultats peuvent être les mêmes pour certaines valeurs et peuvent différer pour un autre ensemble de valeurs. Par conséquent, une telle équivalence n'est généralement pas considérée comme significative.

Équivalence de présentation

Deux planifications sont considérées comme équivalentes dans la présentation si les transactions dans chacune des planifications effectuent des actions similaires de manière similaire.

Par exemple:

• Si T lit les données d'origine dans S1, il lit également les données d'origine dans S2.
• Si T lit la valeur écrite par J dans S1, alors il lit également la valeur écrite par J dans S2.
• Si T termine l'écriture des valeurs dans S1, il termine également l'écriture des valeurs dans S2.

Équivalence de conflit

Deux planifications seront en conflit si elles ont les propriétés suivantes:

• Ils appartiennent à différentes transactions.
• Ils accèdent aux mêmes données.
• L'une d'entre elles au moins est l'opération «d'écriture».

Deux plannings avec plusieurs transactions avec opérations en conflit ne sont considérés comme équivalents à un conflit que si:

• Les deux planifications contiennent le même ensemble de transactions.
• L'ordre des paires d'opérations en conflit est pris en charge dans les deux planifications.

Remarque - Les planifications équivalentes dans la présentation sont sérialisables dans la présentation et les planifications équivalentes aux conflits sont sérialisables par les conflits. Tous les plannings sérialisables par conflit sont sérialisables par présentation.

Statut de la transaction

Une transaction dans une base de données peut être dans les états suivants:

• Actif (Actif) - dans cet état, la transaction commence à être exécutée. Il s'agit de l'état initial de toute transaction.
• Partiellement engagé - Lorsqu'une transaction termine son opération finale, elle est considérée comme étant dans un état partiellement parfait.
• Échec - Une transaction est considérée comme ayant échoué si l'une des vérifications effectuées par le système de récupération de base de données a échoué. Une telle transaction ne peut pas continuer.
• Abandonné - si une vérification échoue et que la transaction passe à un état d'échec, le gestionnaire de récupération annulera toutes les opérations d'écriture dans la base de données pour la remettre à son état d'origine avant le début de la transaction.
  Les transactions dans cet état sont considérées comme interrompues. Le module de récupération de base de données peut sélectionner l'une des deux opérations une fois la transaction interrompue:
  
  
  • Redémarrez la transaction;
  • Annuler la transaction.
• Parfait - si la transaction a réussi toutes les opérations, elle est considérée comme parfaite. Tous ses effets sont enregistrés en permanence dans le système de base de données.

LA FIN

Comme toujours, nous attendons des commentaires, une question qui peut être posée ici et dans une leçon ouverte avec Alexei .