Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Module 7: Les transactions Les transactions • La création d’une base de données

Module 7: Les transactions Les transactions • La création d’une base de données ne prenant en charge qu’un utilisateur simple n’est pas très utile. Le contrôle de multiples utilisateurs mettant à jour les mêmes données. La simultanéité des données signifie que de nombreuses personnes peuvent accéder au mêmes données en même temps, alors que l’uniformité des données signifie que les résultats visualisés par une personne sont cohérents à l’intérieur d’une ou plusieurs transactions courantes. Les transactions • Une transaction est un ensemble d’ordres SQL qui ont pour objectif de faire passer la base de données, en une seule étape, d’un état cohérent à un autre état cohérent. • Une transaction qui réussit, modifie la base de données dans un nouvel état cohérent. Si elle échoue (volontairement ou involontairement), les modification déjà effectuées dans la base sont annulées (défaites), de sorte qu’elle retrouve l’état cohérent antérieur au début de la transaction. C’est oracle qui se charge entiérement de toute cette gestion. Les transactions • Les transactions composées d’une suite d'opérations, gagnent à être aussi petites que possible. Afin qu’une série d'opérations sont considérées comme une transaction, elle doit présenter les propriétés suivantes: • Atomicite: Une transaction doit être une unité atomique de travail; elle ne peut réussir que si toutes ses opérations réussissent. • Coherence: Quand une transaction est terminée, elle doit laisser les données dans un état cohérent incluant toute les règles d’intégrité de données. • Isolation: Les transactions doivent être isolées de changement effectues par d’autres transaction, soit avant que la transaction ne démarre, soit avant le démarrage de chaque opération dans la transaction. Ce niveau d’isolation est configurable par l’application. • Durabilité: Une transaction doit être récupérable aussitôt qu’elle est terminée. Même si un échec du système se produit après la fin des transacions, les effets de la transaction sont permanentes dans le système. Les transactions • Attention: Bien que de nombreuses personnes considèrent que les transactions sont des groupes d’instruction SQL, en fait chaque instruction SQL est une transaction. • Si une erreur se produit pendant l’exécution d’une simple instruction SQL, le travail effectue par cette instruction est annule comme s’il ne s’était jamais produit; c’est le niveau d’instruction uniforme. • Pour être sur de l’uniformité des données quand on développe des applications, il suffit de grouper logiquement plusieurs instructions SQL dans une transaction simple. Celle-ci peut alors traitée comme unité simple de travail en utilisant les ordres de contrôle des transactions. Les transactions • Une transaction commence à l’ouverture de la session ou à la fin de la précédente transaction. La toute première transaction débute au lancement du programme. Il n’existe pas d’ordre explicite de début de transaction. • La fin d’une transaction peut être définie explicitement par un COMMIT ou un ROLLBACK. Les transactions • COMMIT: termine une transaction par la validation des données. Il rend définitives et accessibles aux autres utilisateurs toutes les modifications effectuées pendant la transaction en les sauvegardant dans la base de données, et annule tous les verrous positionnes pendant la transaction (voir mécanisme de verrouillage). • ROLLBACK: termine une transaction en annulant toutes les modifications de données effectuées et annule toutes les verrous positionnes pendant la transaction. Les transactions • La fin d’une transaction peut aussi être implicite et correspondre à l’un des évènements suivants: • L’exécution d’un ordre de définition d’objet (CREATE, DROP, ALTER, GRANT, REVOKE, TRUNCATE etc.). • L’arrêt normal d’une session par EXIT; il se solde par la validation de la transaction en cours; • L‘arrêt anormal d’une session par l’annulation de la transaction en cours. Les transactions • La fin d’une transaction peut aussi etre implicite et correspondre à l’un des evenements suivants: • L’exécution d’un ordre de definition d’objet (CREATE, DROP, ALTER, GRANT, REVOKE, TRUNCATE etc.). • L’arret normal d’une session par EXIT; il se solde par la validation de la transaction en cours; • L‘arret anormal d’une session par l’annulation de la transaction en cours Les transactions • En cas d’arret brutal de la machine qui heberge la base de donnees, Oracle garantit que toutes les transactions déjà validées par un COMMIT ou un ROLLBACK seront assurées. Au redemarrage de l’instance efface toutes les transactions en cours qui n’etaient ni validees, ni supprimees. Ce mecanisme ne necessite aucune intervention de l’administrateur. Les transactions • Il est possible de subdiviser une transaction en plusieurs etapes en sauvegardant les informations à la fin de chaque etape, tout en gardant la possibilite soit de valider l’ensemble des mises à jour, soit de modifier tout ou partie des mises à jour à la fin de la transaction. • Le decoupage de la transaction se fait en inserant des points de repere, ou SAVEPOINT. • Les points de repères (SAVEPOINT) sont des points de controles utilises dans les transactions pour annuler partiellement l’une d’elles. Dans ce cas, un savepoint est defini par un identifiant et peut etre referencé dans la clause ROLLBACK. Les transactions • Une transaction peut s’isoler des autres transactions. C’est obligatoire dans les systèmes de BD à utilisateurs multiples pour maintenir l’uniformité des données à utilisateurs multiples pour maintenir l’uniformité des données. La norme SQL-92 définit quatre niveaux d’isolation pour les transactions s’étendant d’une uniformité très faible à une uniformité très forte. • Pourquoi n’employerait on pas le niveau le plus fort pour toutes les transactions? C’est une question de ressource. Plus le niveau d’isolation est fort, plus le verrouillage des ressources est intense. De plus, cela réduit le nombre d’utilisateurs pouvant accéder aux données simultanément. Les transactions • Chacun de ces niveaux d’isolation peut produire certains effets secondaires connu sous le nom de DIRTY READ (lecture incohérente). FUZZY READ (lecture non reproductible) et PHANTOM READ (lecture fantôme). Seules les transactions avec un niveau d’isolation de type SERIALISABLE sont immunisées. Lecture incohérente (DIRTY READ) T1 T2 UPDATE enregistrement SELECT enregistrement ROLLBACK Lecture incoherente • La transaction T2 met à jour sans poser de verrou; celui-ci est disponible directement pour les autres transactions (exemple T1). Cette lecture peut être erronée, particulièrement si la transaction T1 annule l’effet de la modification avec la commande ROLLBACK. La lecture faite par la transaction T1 est fausse, on la nomme DIRTY READ (lecture incohérente). Lecture non répétitive (Fuzzy Read) T1 T2 SELECT enregistrement UPDATE (enregistrement) COMMIT SELECT enregistrement Lecture non repetitive • La transaction T1 consulte un enregistrement (pour contrôler sa disponibilité par exemple) et, dans la suite de la transaction, le consulte à nouveau (pour le mettre à jour). Si une seconde transaction T2 modifie l’enregistrement entre les deux lectures, la transaction T1 va lire deux fois le même enregistrement, mais obtenir des valeurs différentes. La lecture faite par la transaction est une lecture non répétitive. Lecture fantome T1 T2 SELECT enregistrement 1 SELECT enregistrement 2 SELECT enregistrement 3 DELETE enregistrement 3 UPDATE enregistrement 1 SELECT enregistrement 4 UPDATE enregistrement 4 SELECT enregistrement 5 INSERT enregistrement 6 Commit Lecture fantôme • La transaction T1 lit un ensemble d’enregistrement répondant à un critère donne à des fin de décomptes ou d’inventaire. Parallèlement, la transaction T2 modifie les données. Au départ, il y’a cinq enregistrements satisfaisant le critère. La transaction T1 lira en fin de compte quatre enregistrements satisfaisant le critère, de façon tout à fait incohérente, puisque l’enregistrement 3 est supprimé, les enregistrement 4 et 1 sont modifies et un nouvel enregistrement 6 apparait. Les niveaux d’isolation Le niveau d’isolation indique le comportement de la transaction par rapport aux autres transactions concurrentes. Plus le niveau d’isolation est faible, plus les autres transactions peuvent agir sur les données concernées par la première. READ UNCOMMITED Le plus faible niveau restrictif permet à une transaction de lire des données qui ont été changées mais non validées. READ COMMITED C’est le paramètre par défaut ORACLE. Il assure que chaque requete dans une transaction lit seulement les données validées. REPEATABLE READ Ce niveau permet à une transaction de lire les mêmes données plusieurs fois avec la garantie qu’elle recevra les mêmes résultats à chaque fois. Vous pouvez le réaliser en plaçant des verrous sur les données qui sont lues et ainsi vous assurez qu’aucune autre transaction ne les modifiera pendant la durée de la transaction considérée. Ce mode assure la reproductibilité ou répétitivité des lectures. SERIALIZABLE Avec ce niveau le plus restrictif, une transaction ne prend en compte que les données validées avant le démarrage de la transaction, ainsi que les changements effectués par la transaction. Le choix du juste niveau d’isolation pour vos transactions est important. Bien que les transactions avec un niveau de type SERIALIZABLE assurent une protection complète, elles affectent également la simultanéité en raison de la nature des verrous places sur les donnes. C’est la nature de votre application qui détermine le meilleur niveau. Niveaux d’isolation d’Oracle Oracle choisit de prendre en charge les niveaux d’isolation de transaction READ COMMITED et SERIALIZABLE avec un autre niveau appelé READ ONLY (lecture seule). Le niveau READ ONLY est semblable à REPEATABLE READ, car on ne peut voir que les changements validés au démarrage de la transaction; cependant comme son nom le suggère, il est uploads/Finance/ module-7-transaction.pdf