Remerciez-le!

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

Bachtarzi.C Cours : bases de données avancées Niveau : Master 1 SI -1- Chapitre

Bachtarzi.C Cours : bases de données avancées Niveau : Master 1 SI -1- Chapitre III Gestion des transactions III-1-Définition : Une transaction est une série d'opérations qui apparaissent sous la forme d'une large opération atomique. Soit la transaction réussit, soit elle échoue. Exemple : transfert de compte à compte bancaire : on enlève sur un compte, on dépose sur l'autre… Dans la définition du langage SQL, on peut la définir comme un ensemble d’ordres SQL qui manipulent les données d’une base de données cohérente et doivent restituer à la fin une base dans un état cohérent. Transaction début . . → ordres SQL . fin III-2- Caractéristiques d’une transaction : Propriétés d’une transaction (ACID) III-2-1) Atomicité : La transaction est considérée comme un élément atomique, c à d une fois lancée, elle s’exécute jusqu’au bout ou pas du tout. III-2-2) Cohérence : une transaction doit pouvoir manipuler des données cohérentes et assurer leur intégrité. III-2-3) Isolation : si deux ou plusieurs transactions s’exécutent simultanément, il ne doit pas y avoir d’interférence entre elles. Leur exécution se fait comme si elles étaient lancées séquentiellement. III-2-4) Durabilité : une panne du système ne doit pas influer sur les résultats d’une transaction qui s’est exécutée normalement. Transaction B.D. état B.D. état cohérent cohérent III-3- Fin d’une transaction : une transaction a deux issues possibles COMMIT : en cas de succès, et dans ce cas toutes les opérations faites sur la base sont validées. et on ne peut plus en annuler aucune En d’autres termes les mises à jour deviennent définitives. ROLL BACK : en cas d’échec, les modifications apportées à la base sont annulées depuis le dernier commit ou rollback, ou depuis le premier ordre SQL s’il n’y a ni commit ni rollback. Points de contrôle : appelés Save Points, ils sont utiles pour annuler une partie d’une transaction. Bachtarzi.C Cours : bases de données avancées Niveau : Master 1 SI -2- Début transaction ordre SQL1 ordre SQL2 Save point SP1 ordre SQL3 Si condition X alors ROLL BACK to SP1 finsi ordre SQL4 Fin transaction III-4- Transactions réparties : Dans le cas d’une transaction répartie, il faut s’assurer que toutes les mises à jour d’une transaction sont exécutées sur tous les sites ou qu’aucune ne l’est. Si le contrôle est réparti, chaque site peut décider de valider ou d’annuler. Le problème revient donc à coordonner les validations inter-sites. Validation en deux phases : C’est un protocole qui a été proposé dans le but de coordonner l’exécution des commandes COMMIT par tous les sites concernés par une transaction. Principe : Le contrôle de la transaction répartie est centralisé au niveau d’un site appelé site coordinateur. Les autres sites sont appelés participants. Ces derniers doivent obéir aux commandes du coordinateur, à savoir : préparation, validation ou annulation d’une transaction. L’opération de validation se déroule en 2 phases. Phase 1 : cette phase consiste à préparer l’écriture des résultats des mises à jour dans la BD. Phase 2 : Si la phase 1 se termine avec succès, la phase 2 est lancée. Elle consiste à reporter toutes les opérations des mises à jour dans la BD Dialogue coordinateur-participant : Coordinateur Participant Préparer Préparation Prêt/non prêt Valider/Abandonner Fin Validation Bachtarzi.C Cours : bases de données avancées Niveau : Master 1 SI -3- • Validation normale en commit à deux phases : P1 Coordinateur P2 Prépare Prépare Prêt Prêt Valider Valider Fin Fin Le protocole 2PC résout les problèmes de panne sur une courte durée. Types de pannes : - Panne réseau - Panne du SGBD - Panne d’un site • Panne d’un participant avant d’être prêt : P1 Coordinateur P2 Prépare Prépare Panne Prêt Annuler Annuler Reprise Fin Fin • Panne d’un participant après s’être déclaré prêt : P1 Coordinateur P2 Prépare Prépare Prêt Prêt Valider Valider Panne Fin Reprise Prêt Valider Fin Il est possible de récupérer après une éventuelle panne et de continuer le protocole de validation, car chaque participant détient un journal local qui contient l’état des transactions Bachtarzi.C Cours : bases de données avancées Niveau : Master 1 SI -4- • Panne du coordinateur avant la réception des messages prêt : P1 Coordinateur P2 Prépare Prépare Prêt Prêt Panne Reprise Prépare Prépare Prêt Prêt Valider Valider Fin Fin Inconvénient du protocole 2PC : En cas de panne du coordinateur, les participants qui se sont déclarés prêts restent bloqués en attente de la reprise du participant. III-5- Introduction à la concurrence d’accès : La concurrence d’accès complique la gestion des transactions. Nécessité d'exécuter les programmes et requêtes simultanément. Le problème : Garantir : - La cohérence de la base de données - L’exécution correcte des programmes Exemples de contextes hautement concurrentiels: - annuaires téléphoniques (accès en lecture) - systèmes de réservation de billets (lecture et mise à jour) En considérant que l’exécution de plusieurs transactions en série est correcte, l’idée est de ramener une exécution concurrente à une exécution en série. A =25 T1 T2 t1 R (A) t2 A :=A+100 t3 W(A) t4 R (A) t5 A:=A*2 t6 W(A) T1 puis T2 : A = 250 Problèmes à éviter: - Perte de mise à jour - Ligne fantôme - Lectures impropres (sales) - Lectures non reproductibles Bachtarzi.C Cours : bases de données avancées Niveau : Master 1 SI -5- III-5-1- Perte de mise à jour : A =1000 A=1000 T1 T2 T1 T2 t1 R(A) R(A) t2 A :=A+3000 R(A) t3 W (A) A :=A+3000 t4 R(A) W (A) t5 A :=A+500 A :=A+500 t6 W(A) W(A) A= 4500 Mise à jour faite par T1 perdue : A = 1500 III-5-2- Ligne fantôme : Il ∃ L1 L2 et dans ces lignes A1=5, A2=10, S=0 Il ∃ L1 L2 et dans ces lignes A1=5, A2=10, S=0 T1 T2 T1 T2 t1 S=S+A1 S=S+A1 t2 S=S+A2 Insert A3=30 t3 S=15 Delete L2 t4 S=S+A2 t5 Insert A3=30 S=35 t6 Delete L2 t7 S=15 L2 est ligne fantôme III-5-3-Lecture impropre: A =1000 A =1000 T1 T2 T1 T2 t1 R(A) R(A) t2 A :=A+3000 A :=A+3000 t3 W (A) W (A) t4 Rollback R(A) t5 A=1000 Rollback t6 R(A) A=1000 t7 A :=A+500 A :=A+500 t8 W(A) W(A) A= 1500 3000 unités de trop Bachtarzi.C Cours : bases de données avancées Niveau : Master 1 SI -6- III-5-4-Lecture non reproductible: A =1000 A =1000 T1 T2 T1 T2 t1 R(A) R(A) t2 … R(A) t3 R(A) A :=A+500 t4 A :=A+3000 Commit t5 W (A) A=1500 t6 R(A) R(A) t7 A :=A+500 A :=A+3000 t8 W(A) Commit A= 4500 A=4500 500 unités de trop Notions d’ordonnancement : Ordonnancement : séquence d’actions obtenues en intercalant les actions de plusieurs transactions tout en préservant l’ordre interne des actions de chaque transaction. Ordonnancement série : ordonnancement qui n’entrelace pas les actions des différentes transactions. Deux ordonnancements O1 et O2 sont équivalents si leurs effets sont identiques. Un ordonnancement est sérialisable s’il est équivalent à un ordonnancement série. Exemple: Soit T1=RT1(A), RT1(B), WT1(A), WT1(B), commitT1 et T2=RT2(A), WT2(C), WT2(A), commitT2 O = RT1(A), RT2(A), RT1(B), WT1(A), WT1(B), WT2(C), WT2(A), commitT2, commitT1 Remarque: si chaque transaction préserve la consistance de la base alors, tout ordonnancement sérialisable de ces transactions préserve aussi la consistance de la base. III-5-4- Approches de gestion de la concurrence : Deux méthodes : - Verrouillage à 2 phases - Tri des estampilles III-5-4-1- Verrouillage : L’idée est simple : on bloque l’accès à une donnée dès qu’elle est lue ou écrite par une transaction («pose de verrou») et on libère cet accès quand la transaction termine par commit ou rollback («libération du verrou ») Le verrou partagé (SLocks) : permet d’accorder à plusieurs transactions l’accès au même élément si toutes en demandent l’accès dans le seul but de le lire. Le verrou exclusif (XLocks) : Utilisé par toute transaction qui a besoin d’effectuer une opération d’écriture sur un élément. Bachtarzi.C Cours : bases de données avancées Niveau : Master 1 SI -7- Verrous exclusif : protocole PX - Toute transaction d’accès contient implicitement une demande de verrouillage - verrouiller(X). Toute transaction qui a besoin d’une ressource qui est actuellement verrouillée est mise en attente (FIFO). - L'obtention du verrou autorise lectures et mises à jour. - Un verrou peut être relâché explicitement déverrouiller(X) à n’importe quel moment. Au plus tard, il est relâché implicitement à la fin de la transaction. Exemple : T1 T2 t1 XLire(A) t2 XLire(A) t3 Ecrire(A) Mise en attente t4 ¦ t5 ¦ t6 Xrelâcher(A) Mise en attente de T2 jusqu’à ce que A relâche le verrou. Plus de perte de mise à jour. Verrous partagés : o Chaque transaction doit obtenir un verrou partagé S (shared) sur un granule avant de le lire, et un verrou exclusif X (exclusive) sur un granule avant d’effectuer une écriture dessus. o Tous les verrous émis par une transaction sont libérés à sa terminaison. o Si une transaction obtient un verrou X sur un granule, aucune transaction ne peut obtenir un verrou (S ou X) uploads/Finance/ gestion-des-transactions.pdf