Gestion des Journaux. Méthodes d accès aux données. Système d exploitation. Gestion de Verrous. Gestion de. Mémoire. Gestion de transactions Page 2

Transcription

1 Gestion de Transactions Principes de base Propriétés ACID d'une transaction Protocoles de contrôle de concurrence Protocoles de tolérance aux pannes Gestion de transactions dans Oracle Modèles de transactions avancés Transactins longues et coopérantes Transactions réparties Protocoles de validation atomique Standards X/Open et OSI-TP Modèles de réplication Gestion de transactions Page 1 Définition d une transaction Transaction = séquence d'instructions d un programme de base de données faisant passer la base d un état cohérent à un état cohérent. Incohérence possible... Etat cohérent Etat cohérent Begin Rollback Transaction Begin CEpargne = CEpargne CCourant = CCourant Aucune opération ne peut être exécutée hors transaction (transactions chaînées) Une transaction peut se terminer par une validation () ou un abandon (Rollback) Gestion de transactions Page 3 Architecture en couches d un SGBD Interface Analyseur sémantique Optimiseur Evaluateur de plan d exécution Opérateurs relationnels Méthodes d accès aux données Gestion de Mémoire Gestion de Verrous Gestion des Journaux Système d exploitation Gestion de transactions Page 2 Propriétés ACID d'une transaction Atomicité Une transaction doit s exécuter en tout ou rien Cohérence Une transaction doit respecter l ensemble des contraintes d intégrité Isolation Une transaction ne voit pas les effets des transactions concurrentes Durabilité Les effets d une transaction validée ne sont jamais perdus, quel que soit le type de panne On parle de contrat transactionnel entre l utilisateur/programme et le SGBD Gestion de transactions Page 4

2 Accès concurrent: les problèmes (1) Remarque : les transactions concurrentes s exécutent dans des threads/processus différents Perte d'opération LIRE (X, A1) LIRE (X, A2) A2 <- A2 + 1 ECRIRE (X, A2) A1 <- A1 + 1 ECRIRE (X, A1) Gestion de transactions Page 5 Accès concurrent: les problèmes (3) Introduction d'incohérences Contrainte d'intégrité : X = Y LIRE (X, A1) A1 <- A1 + 1 ECRIRE (X, A1) LIRE (Y, B1) B1 <- B1 + 1 ECRIRE (Y, B1) LIRE (X, A2) A2 <- A2 * 2 ECRIRE (X, A2) LIRE (Y, B2) B2 <- B2 * 2 ECRIRE (Y,B2) Gestion de transactions Page 7 Accès concurrent: les problèmes (2) Observation d'incohérences Contrainte d'intégrité : X = Y LIRE (X, A1) A1 <- A1-500 ECRIRE (X, A1) LIRE (Y, A1) A1 <- A1-500 ECRIRE (Y, A1) LIRE (X, A) EDITER (A) LIRE (Y, B) EDITER (B) Gestion de transactions Page 6 Accès concurrent: les problèmes (4) Lectures non reproductibles LIRE (X, A1) A1 <- A1 + 1 ECRIRE (X, A1) LIRE (X, A2) EDITER (A2) LIRE (X, A2) EDITER (A2) Gestion de transactions Page 8

3 Exécution sérialisable Exécution sérialisable : une exécution en parallèle des transactions,..., Tn est dite sérialisable si son résultat est équivalent à une exécution en série quelconque de ces mêmes transactions. Les actions A et B sont commutables/permutables si toute exécution de A suivie par B donne le même résultat que l'exécution de B suivie par A. Si une exécution de transactions est transformable par commutations successives en une exécution en série, alors elle est sérialisable. LECT(O1) T3 ECR(02) Exemple d'exécution sérialisable T3 TEMPS LECT(O1) ECR(O2) LECT(O2) ECR(O1) LECT(O1) LECT(O2) LECT(O1) ECR(O1) Gestion de transactions Page 9 Relation de précédence Ti précède Tj dans l ordre de sérialisation s' il existe deux actions non permutables ai et aj tel que ai soit exécutée par Ti avant que aj soit exécutée par Tj Exemple : T3 LECT(O1) LECT(O2) ECR(O2) LECT(O2) ECR(O1) T3 Si le graphe de précédence d'une exécution est sans circuit, l'exécution est sérialisable. Gestion de transactions Page 11 Exemple d'exécution non sérialisable T3 LECT(O1) LECT(O2) ECR(O2) LECT(O2) ECR(O1) T3 T3 T3 ETC... TEMPS Gestion de transactions Page 10 Ordonnancement par estampillage Estampille (TimeStamp) associée à chaque transaction date de lancement ou compteur Introduit une relation d'ordre total entre les transactions Conservation des estampilles dans les granules Granule = objet de la BD considéré comme unité de contrôle Writer = dernier écrivain Reader = plus jeune lecteur Contrôle d'ordonnancement en écriture: estampille écrivain > Writer et > Reader en lecture: estampille lecteur > Writer Toute transaction arrivant en retard est abandonnée Les arcs du graphe de précédence sont donc dans l ordre des estampilles pas de circuit possible Ordonnancement multi-versions (optimisation) Toute lecture est servie avec une version Seules les écriture dans le passé sont refusées Problèmes Risque d'effet domino (abandon en cascade) Gestion de transactions Page 12

4 Ordonnancement par certification Approche optimiste Basée sur l hypothèse que les conflits sont peu fréquents Une transaction est décomposée en trois phases: - 1 phase de calcul pendant laquelle la transaction effectue ses mises à jour dans une mémoire privée et maintient : - Read-set = ensemble des objets lus par la transaction - Write-set = ensemble des objets modifiés par la transaction - 1 phase de certification afin de détecter les conflits - 1 phase de validation pendant laquelle les données modifiées sont reportées de la mémoire privée dans la base de données Gestion de transactions Page 13 VERROUILLAGE 2 PHASES OBJECTIF LAISSER S'EXECUTER SIMULTANEMENT SEULEMENT LES OPERATIONS COMMUTABLES Lecture Ecriture Lecture 1 0 Ecriture 0 0 MOYEN LES TRANSACTIONS VERROUILLENT LES OBJETS AUXQUELLES ELLES ACCEDENT LES TRANSACTIONS CONFLICTUELLES SONT MISES EN ATTENTE (PLUTOT QUE D ETRE ABANDONNEES) Gestion de transactions Page 15 Ordonnancement par certification deb(ti) et fin(ti) = date de début et fin de phase de calcul date_valid(tj) = date de validation de Tj Certifier(Ti) Tj / deb(ti) < date_valid(tj) < fin(ti) si Write-set(Tj) Read-set(Ti) = Ø alors /* Ti peut être validée */ date_valid(ti) = date; sinon abort(ti) Que se passe-t-il si l hypothèse de départ n est pas satisfaite (i.e., conflits nombreux)? Gestion de transactions Page 14 Condition de Bon Fonctionnement TOUTE TRANSACTION DOIT ETRE COMPOSEE DE DEUX PHASES : ==> 2PL (Two Phase Locking) Nombre d'objets Phase de verrouillage Phase de libération Temps LE DEVERROUILLAGE S'EFFECTUE EN FIN DE TRANSACTION AFIN D'EVITER QU'UNE TRANSACTION PUISSE VOIR DES MISES A JOUR NON VALIDEES (DIRTY READS) Gestion de transactions Page 16

5 Problème du verrou mortel T3 T4 Prévention DIE_WAIT : une jeune transaction se tue si elle rentre en conflit avec une transaction plus vieille. Elle est relancée avec la même estampille WOUND_WAIT : une vieille transaction blesse une transaction plus récente en cas de conflit Détection on construit le graphe des attentes au fur à mesure des conflits. Si un cycle est détecté, on abandonne une des transactions du cycle Gestion de transactions Page 17 Verrouillage par intention (ou hiérarchique) Objectif: faire varier le granule de verrouillage afin d'éviter un trop grand nombre de verrous lorsque beaucoup d'objets sont accédés Exemple: Parcours séquentiel d'une relation verrouille des granules page ==> lock pages en S Modification de tuples verrouille des granules objet ==> lock pages accédées en IX et les tuples modifiés en X S'applique à tout verrouillage hiérarchique BD Tables Pages Tuples Document Chapitres Sections - Paragraphes noeuds non feuilles verrouillés en intention (IS, IX ou SIX) et noeuds feuilles verrouillés en S ou X Gestion de transactions Page 19 Equation du Verrouillage LE COUT DEPEND DE LA TAILLE DES GRANULES : DES PETITS GRANULES (Tuple) CONDUISENT A UN COUT IMPORTANT MAIS MAXIMISENT LE PARALLELISME DE LARGES GRANULES (Page, Table) CONDUISENT A UN TEMPS D'ATTENTE IMPORTANT MAIS MINIMISENT LE PARALLELISME UNE TAILLE VARIABLE EST SOUHAITABLE SOLUTIONS : VERROUILLAGE PAR INTENTION DEGRES D'ISOLATION (NORME SQL2) Gestion de transactions Page 18 Verrouillage sémantique Le verrouillage standard ne distingue que les modes Read et Write Verrouillage sémantique ex, objet compteur avec les méthodes: incrémenter, décrémenter, lire incr decr lire incr decr lire Coût et complexité du paramétrage de la matrice Prise en compte des contraintes de commutabilité Nécessite une journalisation logique Gestion de transactions Page 20

6 Degrés d'isolation SQL Objectif: accroître le parallélisme en autorisant certaines transactions à violer la règle d'isolation Degrés standardisés SQL2 (Set Transaction Isolation Level) Degré 0 (Read Uncommitted)» Lecture de données sales Interdiction d écrire.» Ex. lecture sans verrouillage Degré 1 (Read ted)» Lecture de données propres Ecritures autorisées» Ex. Verrous court en lecture, long en écriture Degré 2 (Repeatable Read)» Pas de lecture non reproductible» Ex. Verrous longs en lecture et en écriture Degré 3 (Serializable)» Pas de requête non reproductible (fantôme) Gestion de transactions Page 21 ARIES-KVL : Mohan Idée = verrouiller des prédicats en verrouillant des clés d'index Exemple : select * from Voiture V where V.couleur="rouge" verrouille la clé "rouge" dans l'index couleur Toute insertion ou suppression d'une voiture rouge est donc interdite Le verrou sur une clé est stocké à l'extérieur de l'index et est accédé par une fonction de hachage sur la valeur de clé S'il n'y a pas d'index sur "couleur", on force quand même l'accès à la clé "rouge" Suffisant pour exact match predicates Gestion de transactions Page 23 Degrés d'isolation SQL : exemples ( 0, Read uncommitted) ( 3,serializable) ( 1, Read committed) ( 3,serializable) Begin Begin Lit CC ( 100) Lit CC ( 100) Ecrire CC, CC+10 Lit CC ( 110) Ecrire CC, CC+20 Lit CC ( 130) Begin Begin Lit CC ( 100) Lit CC ( 100) Ecrire CC, CC+10 Lit CC ( bloque) Ecrire CC, CC+20 ( 130) ( 2, Repeatable read) ( 3,serializable) Begin Begin Lit CC ( 100) Lit CC ( 100) Ecrire CC, CC+10 Lit CC ( 100) bloque Lit CC ( 100) Ecrire CC, CC+20 ( 2, Repeatable read) ( 3,serializable) Begin Select count(*) from Voit where couleur="rouge" Begin Insert into Voit values (R4, "rouge") Select count(*) from Voit where couleur="rouge" Gestion de transactions Page 22 ARIES-KVL : (suite) Méthode insuffisante pour des range predicates Exemple : select * from Voiture V where V.puissance between 8 and 11 Toutes les clés possibles du range devraient être verrouillées mais seules celles existant dans l'index à un instant t peuvent l'être - ex: clés présentes dans l index 7, 9, 12 possibilité d insérer 8 ou 10 qui satisfont le prédicat Afin d'éviter l'insertion d'une nouvelle clé dans le range - la lecture verrouille en S toutes les clés présentes dans l index satisfaisant le prédicat ainsi que la clé suivante (dans l exemple : 9 et 12) Gestion de transactions Page 24

7 Isolation dans les SGBD commerciaux Oracle Corporation Oracle Transactions chaînées Cohérence : verrouillage hiérarchique et versionning Transactions lectrices jamais bloquées par les écrivains IBM DB2 Transactions chaînées Cohérence : verrouillage hiérarchique Bloquage Transactions lectrices / transactions écrivains Microsoft SQL Server Transactions chaînées Cohérence : verrouillage hiérarchique Bloquage Transactions lectrices / transactions écrivains Gestion de transactions Page 25 Concurrence dans Oracle (2) Exercice : 2 fenêtres, 1 variable solde Réponse attendue??? where N_compte = where N_compte = 1000 euros En attente 1000 euros Update compte set solde=2000 where N_compte = where N_compte = 1000 euros 27 Concurrence dans Oracle (1) Exercice : 2 fenêtres, 1 variable solde Réponse attendue??? where N_compte = where N_compte = Update compte set solde=2000 where N_compte = where N_compte = Concurrence dans Oracle (3) Exercice : 2 fenêtres, 1 variable solde Réponse Réelle where N_compte = where N_compte = 1000 euros 1000 euros 2000 euros Ok Update compte set solde=2000 where N_compte = where N_compte = 2000 euros Conclusion??? 26 28

8 Concurrence dans Oracle (4) Exercice : 2 fenêtres, 1 variable solde 1000 euros Le where protocole N_compte Oracle = est multi-versions 1000 euros where N_compte = On voit les mises à jour, degré d isolation par défaut : Read ted Réponse Réelle 2000 euros Ok Pas de verrou en lecture (seulement en écriture) Update compte set solde=2000 where N_compte = where N_compte = 2000 euros Conclusion??? Concurrence dans Oracle (6) Niveau Read ted Offre un cliché stable des données pendant la requête Mécanisme de version par utilisation des Rollback Segments (images avant) Verrous en écriture, bloquant seulement d autres écritures Problème de restitution des images avant pour les vieilles requêtes A = 10 SCN=5 Transaction Ecriture A=20 Lecture A=10 Lecture A=10 Transaction A = 20 SCN=10 A = 10 SCN=5 B = 13 SCN=7 C = 11 SCN=3 D = 15 SCN=1 Images avant Concurrence dans Oracle (5) 2 niveaux d isolation supportés (de la norme SQL2) Read ted (par défaut) Données stabilisées pendant une requête Serialisable Données stabilisées pendant toute la transaction Mais aussi Read only (i.e. Repeatable Read en lecture seule) Données stabilisées pendant toute la transaction, écritures interdites Verrous de granule tuple Verrouillage hiérarchique tuple-table Pas d escalade automatique de verrous Deadlocks traités par rollback du dernier statement SQL d une transaction du cycle 30 Chronologie Requête Requête Requête Requête SCN = 7 SCN = 8 SCN = 8 SCN = 9 SCN = 9 SCN = 6 SCN = 10 SCN = 11 Lecture A=20 Écriture A=30 Transaction Données Données B = 13 SCN=7 C = 11 SCN=3 D = 15 SCN=1 SCN = 6 Requête SCN = 11 Écriture A=40 attente Écriture A=40 Concurrence dans Oracle (7) Niveau Serialisable Offre cliché stable des données pendant la transaction Mécanisme de version par utilisation du journal d images avant Verrous seulement en écriture, bloquant d autres écritures Problème de restitution des images avant pour les vieilles transactions SCN = 6 Transaction A = 10 SCN=5 SCN = 9 Transaction B = 13 SCN=7 C = 11 SCN=3 D = 15 SCN=1 Écriture A=20 Lecture A=10 Lecture A=10 Lecture A=10 A = 20 SCN=10 B = 13 SCN=7 C = 11 SCN=3 D = 15 SCN=1 A = 10 SCN=5 Images avant 32 Chronologie Requête Requête Requête Requête SCN = 7 SCN = 8 Données SCN = 9 SCN = 10 SCN = 11 Écriture A=30 la transaction ne peut pas être sérialisée Données

9 Tolérance aux pannes Objectif: Garantir les propriétés d'atomicité et de Durabilité quel que soit le type de pannes. Types de pannes: Transaction failure (ex: deadlock, violation de CI) System failure (ex: panne mémoire) Media failure (panne disque) Communication failure (panne réseau) Gestion de transactions Page 33 Mécanisme de pages ombres Alternative permettant de garantir l'atomicité sans utilisation d'un journal d'images avant Incompatible avec du placement disque Dictionnaire ATDP table des pages pi pi+1 pi+2 pi+3 pi+4 nouvelle table des pages pi pi+1 pj pk pi+4 pj pi pi+1 pi+2 pi+3 pi+4 pk Gestion de transactions Page 35 Atomicité Toutes les mises à jour d'une transaction doivent être prises en compte ou bien aucune ne doit l'être 2 techniques de base Mises à jour en place ==> Règle du Write Ahead Logging (WAL) : Toute mise à jour est précédée d'une écriture dans un journal d'images avant permettant d'invalider cette mise à jour Mises à jour dans un espace de travail ex: mécanisme de shadow pages Gestion de transactions Page 34 Journal d images avant But: pouvoir défaire les mises à jour effectuées à tort Journalisation physique { <Trid, n page, image avant de la page, action > } Journalisation physique différentielle { <Trid, n page, offset1, offset2, image avant de la chaîne offset1-offset2, action > } Journalisation logique { <Trid, opération inverse avec paramètres d'appels> } ex: insert_tuple(t)------> delete_tuple(t) (technique de compensation) Gestion de transactions Page 36

10 Journalisation physique vs logique Avantages d'un journal logique - réduit la taille du journal dans la majorité des cas - permet d'exploiter la commutabilité des opérations logiques. Au contraire, un journal physique impose que le granule de verrouillage soit le même que le granule de journalisation Inconvénients d'un journal logique - ralentit les procédures de reprise après panne - interdit d'écrire sur disque des mises à jour partielles d'une opération logique - certaines opérations logiques sont complexes à inverser Gestion de transactions Page 37 Politiques de gestion de cache (1) La politique de gestion de cache détermine l'instant auquel les pages modifiées dans le cache mémoire sont reportées sur disque Deux paramètres essentiels guident ces politiques STEAL (resp. NO_STEAL) des pages modifiées par des transactions non validées peuvent être reportées sur disque FORCE (resp. NO_FORCE) à la validation d'une transaction, toutes les pages qu'elle a modifiées sont obligatoirement présentes sur disque Gestion de transactions Page 39 Durabilité Objectif: ne jamais perdre de mises à jour validées quel que soit le type de pannes Moyen: mémoriser toutes les mises à jour validées dans un journal d'images après. Ce journal a un format similaire au journal d'images avant Règle du Force Log at : Le journal d'images après d'une transaction doit être écrit sur disque lors de la validation Règle du bon sens: Le journal d'images après doit être stocké sur un disque différent de la base de données Gestion de transactions Page 38 Politiques de gestion de cache (2) 4 politiques possibles STEAL / FORCE STEAL / NO-FORCE NO-STEAL / FORCE NO-STEAL / NO-FORCE Détermine les stratégies d'abandon d'une transaction et de reprise à chaud Gestion de transactions Page 40

11 Abandon d'une transaction Procédure mise en oeuvre lors d'une transaction failure Pour garantir l'atomicité NO-STEAL défaire les mises à jour de la transaction dans le cache uniquement STEAL défaire les mises à jour de la transaction dans le cache défaire les mises à jour de la transaction déjà reportées sur disque Gestion de transactions Page 41 Checkpoint et fast commit Objectif : réduire le temps de latence pendant les validations et abandon de transactions afin de supporter un plus grand nombre de transactions par seconde (Tps) Moyen : - mises à jour du disque par une tâche asynchrone (implantation du STEAL/NO-FORCE) - seul le journal d'images après est écrit sur disque à la validation d'une transaction - complique toutefois les procédures de reprise Abort Abort T3 T4 T5 Abort PANNE Checkpoint Checkpoint Gestion de transactions Page 43 Reprise à chaud Procédure mise en oeuvre lors d'une system failure Pour garantir l'atomicité NO-STEAL ==> rien à faire STEAL ==> défaire les mises à jour reportées sur disque par toutes les transactions non validées au moment de la panne Pour garantir la Durabilité NO-FORCE ==> refaire les mises à jour des transactions validées qui n'avaient pas été reportées avant la panne FORCE ==> rien à faire Gestion de transactions Page 42 Group commit Objectif : réduire le nombre d'e/s nécessaire au commit d'une transaction afin de supporter un plus grand Tps Complémentaire au Fast commit Fast commit => au moins 1 E/S par transaction pour écrire son J+ Incompatible avec un Tps très élevé (ex: 1000 Tps) Solution = grouper les commits de n transactions de sorte à écrire une seule page de J+ pour ces n transactions Attente faible liée au fort Tps Gestion de transactions Page 44

12 Reprise à froid Procédure mise en oeuvre lors d'une media failure RECHARGER LA BASE DE DONNEES AVEC LA DERNIERE VERSION COHERENTE SAUVEGARDEE REFAIRE LES TRANSACTIONS VALIDEES ENTRE LE DERNIER POINT DE SAUVEGARDE ET LA PANNE, EN APPLIQUANT LE JOURNAL DES IMAGES APRES FREQUENCE DES POINTS DE SAUVEGARDE? - détermine la durée de la reprise et la taille du journal d images après - et T4 non validées - et T3 validées (commises) POINT SAUVEGARDE BD cohérente C1 T3 C3 T4 PANNE BD cohérente copie BD Gestion de transactions Page 45 Conclusion Contrôle de concurrence - Seul le verrouillage garantit un minimum d'abandons - Influence déterminante du granule de verrouillage sur les coûts et le parallélisme bénéfice du verrouillage par intention - Mais l isolation coûte toujours très cher chercher des compromis acceptables (ex: degrés d isolation) Reprise après pannes - La journalisation multiplie le nombre d'e/s - Gain en performance group commit, fast commit, journalisation logique Gestion de transactions Page 47 Savepoint intra-transaction Introduction de points de sauvegarde intermédiaires Permet de ne défaire qu une partie de la transaction en cas de problème Begin_Trans update update Savepoint (P1) // sauvegarde du contexte update update If condition Rollback to P1 Gestion de transactions Page 46 Tolérance aux pannes dans Oracle (1) Gestion de cache : steal, no-force Des pages modifiées par des transactions non validées peuvent être reportées sur disque À la validation d'une transaction, toutes les pages qu'elle a modifiées ne sont pas obligatoirement reportées sur disque Gestion de journaux avant et après Journal avant : les Rollback segments Journal après : les fichiers Redo Logs 48

13 Tolérance aux pannes dans Oracle (2) Les Rollback Segments En cas de panne, servent à défaire des mises à jour Un Rollback Segment par transaction active Écritures en Rollback Segments protégées par le journal après les premiers objets restaurés en cas de reprise après panne Partie active Partie inactive Remarque : ce sont ces segments qui sont utilisés pour implémenter le lecture cohérente des données NB : Read Consistency d Oracle Modèles de transactions avancés Tolérance aux pannes dans Oracle (3) Les Redo Logs En cas de panne, servent à refaire les mises à jour perdues Reconstruisent également les Rollback Segments Les Redo Logs sont remplis en mode circulaire On en sauve un sur disque pendant que les autres se remplissent Il doit y avoir au moins deux fichiers formant les Redo Logs Fichier log 1 Fichier log 2 Fichier log 3 Sauvegarde du journal après Écriture sur disque des Redo Logs Au commit (Force Log at ) Lors d un checkpoint (Write Ahead Logging) Quand le buffer cache stockant les logs est rempli au tiers ou après un time-out (Fast ) Limites du modèle de transactions plat (1) Ce modèle garantit les propriétés ACID de chaque transaction Un nombre croissant d'applications (CAO, AGL, télétravail, traitements multibases, ) introduisent de nouveaux besoins transactionnels Exemple : transactions longues et/ou coopérantes - en cas de panne ou d'erreur, toutes les mises à jour d'une transaction ne doivent pas être abandonnées relâcher l'atomicité - Il est délicat de bloquer une transaction sur une ressource verrouillée par une transaction longue - Certains utilisateurs doivent pouvoir échanger des données non validées pour effectuer un travail coopératif relâcher l'isolation Modèles de transactions avancés

14 Transactions emboîtées (1) Une transaction est décomposée en une hiérarchie de soustransactions Une sous-transaction est une unité de reprise - l'abandon d'une sous-transaction implique l'abandon de ses descendants mais pas de ses ancêtres Une sous-transaction est une unité d'exécution indépendante - Isolation des sous-transactions s'exécutant en parallèle - Les sous-transactions peuvent s'exécuter sur le même site ou sur des sites différents les transactions sont ACID alors que les sous-transactions sont AI Modèles de transactions avancés - 53 Transactions emboîtées (3) Règles d'isolation (R1) Seules les transactions feuilles accèdent aux ressources partagées (ex: base de données) (R2) Quand une sous-transaction valide, ses ressources sont héritées par sa mère (R3) Quand une sous-transaction abandonne, ses ressources sont relâchées (R4) Une sous-transaction ne peut accéder une ressource que si elle est libre ou détenue par un ancêtre Modèles de transactions avancés - 55 Transactions emboîtées (2) Vocabulaire racine mère Descendants Ancêtres fille soeurs Accès à la BD Modèles de transactions avancés - 54 Transactions emboîtées (4) Illustration de l'isolation par un mécanisme de verrouillage état initial Objet i 11 verrouille l'objet i Objet i Modèles de transactions avancés - 56

15 Transactions emboîtées (5) cas 1: validation de Objet i cas 2: abandon de Objet i Modèles de transactions avancés - 57 Transactions emboîtées (7) état initial X:=X+1 par 2 X = 0 X = 1 X = X = 2 X:=X+1 par X = 0 X = 1 X = 1 Abandon de 2 X = 0 Validation de 1 Validation de X = 1 X = 0 X = 1 2 Modèles de transactions avancés - 59 Transactions emboîtées (6) Atomicité et Durabilité (R1) Quand une sous-transaction valide, ses effets sont hérités par sa mère (R2) Quand une sous-transaction abandonne, ses effets sont abandonnés (R3) Quand la transaction racine valide, ses effets sont installés dans la base Modèles de transactions avancés - 58 Modèles d'activité ou Workflows transactionnels Idée : construire des enchaînements d opérations quelconques (ex: multibases) ayant des propriétés transactionnelles Exemple: activité agence de voyage accédant à plusieurs serveurs annulation réservation (S3-1 ) S8 S2 abandon S6 S7 abandon réservation Sheraton + Budget S1 S2 S3 S4 S5 S9 saisie S2 réservation avion réservation Hilton + Avis facturation consultation horaires d'avions Modèles de transactions avancés - 60

16 Protocoles transactionnels distribués Résolution duverrou Mortel Distribué 1) PREVENTION - Garantir que le problème ne survient jamais - Combinaison de verrouillage et d'estampillage (DieWait, WoundWait) 2) DETECTION - Construction d'un graphe d'attente global par union des graphes d'attente locaux - En cas de cycle, abandon d'une des transactions du cycle 3) PRESOMPTION - Annulation des transactions n'ayant pas terminé leur exécution après un certain délai (timeout) - Solution normalisée Modèles de transactions avancés Verrou Mortel Distribué La majorité des SGBD sérialisent les transactions grâce à un protocole de verrouillage deux phases Chaque site est capable de détecter un verrou mortel local Un contrôle externe est indispensable pour détecter un verrou mortel intersites SITE 1 SITE 2 T3 SITE 3 Modèles de transactions avancés - 62 Atomicité globale Garantir qu'un ensemble de mises à jour sur plusieurs sites est totalement exécuté ou pas du tout Nécessite un protocole de validation atomique (ACP) Exemple: transfert d'argent entre deux comptes gérés par deux agences bancaires distinctes (Ti) site A DB Serveur débit(c1,m) site B Application crédit(c2,m) Serveur DB (Ti) Modèles de transactions avancés - 64

17 Validation à 2 Phases (2PC) Coordinateur : Le composant système du site qui centralise et pilote le protocole Participant : Le composant système d'un site qui participe à l'exécution de la transaction Phase de vote : Le coordinateur demande à tous les participants s'ils sont capables de valider la transaction Phase de décision : Le coordinateur décide la validation si TOUS les participants votent OK. Il décide l'abandon sinon. Ce protocole doit être tolérant aux pannes Modèles de transactions avancés - 65 Cas Défavorable (1) COORDINATEUR PARTICIPANT PARTICIPANT PREPARE PREPARE READY KO ABORT ABORT ACK ACK Modèles de transactions avancés - 67 Cas Favorable COORDINATEUR PARTICIPANT PARTICIPANT PREPARE PREPARE... READY READY COMMIT COMMIT Sauvegarde des MAJ de la transaction dans un journal... ACK ACK Validation des MAJ de la transaction dans la base de données Modèles de transactions avancés - 66 Cas Défavorable (2) PARTICIPANT COORDINATEUR PARTICIPANT PREPARE PREPARE READY READY COMMIT COMMIT ACK?? COMMIT ACK Modèles de transactions avancés - 68

18 Cas très défavorable (3) PARTICIPANT COORDINATEUR PARTICIPANT PREPARE PREPARE READY READY???? En cas de panne du coordinateur pendant la phase d'incertitude des participants (entre l'envoi du Ready et l'attente de la réponse), les participants sont bloqués => protocole BLOQUANT Modèles de transactions avancés - 69 Protocole OSI-TP Standard Open Systems Interconnect de l'iso [ISO92] Objectifs : - Standardiser la façon d'établir et de gérer les dialogues entre les différents participants d'une même transaction - Standardiser un protocole de validation à 2 phases permettant d'assurer l'atomicité des transactions distribuées - Standardiser la gestion des reprises après pannes dans ce protocole - OSI-TP est un protocole 2PC arborescent Modèles de transactions avancés - 71 Normalisation: protocole OSI-TP et modèle X/Open DTP Interopérabilité : OSI-TP définit un protocole de validation à 2 phases standard permettant à différents gestionnaires de transactions de coopérer pendant la validation d'une transaction TM TM protocole OSI-TP Portabilité : AP X/Open DTP définit des interfaces standards assurant la portabilité des applications, des gestionnaires de transactions et des gestionnaires de ressources RM TM interfaces X-OPEN (API) Modèles de transactions avancés - 70 Protocole 2PC à abandon présumé Ce protocole réduit le nombre de messages et d'enregistrements journalisés : écriture bloquante : écriture non bloquante Coordinateur P1 P2 Coordinateur P1 P2 B C Prepare B R Ready R Prepare Ready R KO A C C Abort Ack_ A F Modèles de transactions avancés - 72

19 X/OPEN DTP Modèle de référence pour Distributed Transaction Processing [1993] Objectif: étendre une sphère transactionnelle à tout type de serveur (SGBD ou non) et assurer la portabilité de tous les composants d'un environnement transactionnel Serveur RPC Application L o g BeginTrans update update Begin Trans TID Ok Ok SGBDR L o g Ok Transaction Manager Modèles de transactions avancés - 73 Modèle DTP avec Transaction Managers coopérants Coordinateur Participant A P A P XATMI TxRPC CPI-C R M T M CR M R M T M CR M XA+ OSI-TP OSI-TP OSI-TP est utilisé pour faire interopérer des TMs hétérogènes Modèles de transactions avancés - 75 Modèle DTP avec un seul Transaction Manager Interface native (ex. SQL) Application (AP) Program Tx tx_begin, tx_commit, tx_rollback, tx_set_timeout, tx_info,... Resource Manager (RM) Xa xa_start, xa_prepare, xa_commit, xa_rollback, xa_recover, ax_register,... Transaction Manager (TM) Modèles de transactions avancés - 74 Modèles de réplication : les règles de correction Sérialisabilité à une copie (one-copy serializability) objets physiques = copies d'un même objet logique Une exécution de transactions sur des objets physiques est sérialisable à une copie si elle est équivalente à une exécution sérialisable de ces mêmes transactions sur les objets logiques correspondants Convergence des copies (eventual consistency) En l'absence de nouvelles mises à jour, toutes les copies d'un même objet finissent par atteindre le même état La convergence est une propriété plus faible que la sérialisabilité à une copie On peut converger vers une valeur qui n a pas de sens pour l utilisateur Modèles de transactions avancés - 76

20 Sérialisabilité à une copie Les objets logiques A et B sont répliqués sur les sites S1 et S2 A1, A2 (resp. B1, B2) sont les objets physiques résultant de la réplication write(a1) write(b1) write(a2) write(b2) read(a1) read(b2) write(a) write(b) read(a) read(b) L'exécution ci-dessus n'est pas sérialisable à une copie mais elle préserve la convergence des copies Modèles de transactions avancés - 77 Propagation synchrone (Eager) Les mises à jour sur un objet sont reportées dans la même transaction, sur l'ensemble de ses réplicas Transaction T site S1 site S2 site S3 write A1 write A2write A3 write B1 write B2write B3 commit commit commit Garantit la sérialisabilité à une copie mais Côut d une validation atomique Impose une connexion permanente à tous les sites Modèles de transactions avancés - 79 Sérialisabilité et convergence dépendent du modèle de réplication 2 modes de propagation des mises à jour Synchrone (Eager) Asynchrone (Lazy) 2 modes de contrôle des copies Symétrique (Update Everywhere) Asymétrique (Primary copy) Donc, 4 modèles de réplication synchrone/symétrique (SS) synchrone/asymétrique (SA) asynchrone/symétrique (AS) asynchrone/asymétrique (AA) Modèles de transactions avancés - 78 Propagation asynchrone (Lazy) Les mises à jour sur un objet sont reportées sur ses réplicas en mode différé, par le biais de transactions indépendantes write A1 write B1 commit sur S1 write A2 write B2 commit sur S2 write A3 write B3 commit T3 sur S3 La cohérence des copies dépend du mode de contrôle choisi (symétrique ou asymétrique) Modèles de transactions avancés - 80

21 Contrôle symétrique vs. asymétrique Symétrique: tout site est autorisé à mettre à jour sa copie locale d'un objet Update A A1 A2 Update A Update A A3 Asymétrique: seule la copie maître peut être mise à jour, les autres copies sont en lecture seule Update A Update A Update A A1 A2 A3 Modèles de transactions avancés - 81 Bilan (suite) Modèles de transactions avancés - 83 Bilan Modèles de transactions avancés - 82 Théorème CAP [Brewer 00,Lynch&Gilbert 02] Un système distribué ne peut pas garantir en même temps : Consistency» Tous les sites voient le même état des données en même temps Availability» Toutes les requêtes de lecture et écriture aboutissent Partition Tolerance» Le système continue à fonctionner malgré des pertes de message Compromis Strong Consistency & Weak Availability» Choix (souvent) traditionnel des SGBD Strong Availability & Eventual Consistency» Choix privilégié des systèmes NoSQL Modèles de transactions avancés - 84

22 Réplication dans Oracle Mécanisme de base permettant de capturer les mises à jour sur un site et de les rejouer sur un autre (Oracle Streams) Mutliples paramétrages permettant d utiliser des combinaisons par défaut ou programmer tout modèle de réplication et écrire ses propres procédures de réconciliation Modèles de transactions avancés - 85 Réconciliation préservant l intention Transformées opérationnelles Principe issu du domaine des éditeurs synchrones Objets répliqués sur chaque site Les opérations exécutées sur 1 site sont diffusées sur les autres Opérations sur objets typés String: InsertCar, DeleteCar Calendar: InsertEvent, DeleteEvent XML: AddNode, DeleteNode, ChangeAttr Assurer les propriétés Causalité Convergence Préservation de l intention Modèles de transactions avancés - 87 Procédures de réconciliation Timestamp chaque objet détient le timestamp de sa dernière opération de mise à jour Si TS(objet) > TS(update) => lost update Opérations commutatives ordre d'exécution indifférent Règles spécifiques à une application priorité à certains sites, à certaines valeurs, à certaines opérations Construction d'un arbre de versions Modèles de transactions avancés - 86 Transformées opérationnelles (1) Usager 1 Usager 2 on systems on systems op1=insérer(3, e') op2=supprimer(10) T(op1,op2)= L'opération transformée de op1 par rapport à op2 one systems on system T(op2,op1)= supprimer(11) T(op1,op2)= insérer(3, e') one system one system Modèles de transactions avancés - 88

23 Transformées opérationnelles (2) Pour utiliser l environnement Définir les fonctions «Transpose» pour tous les couples d opérations» Transp(op1,op1)» Transp(op1,op2)» Transp(op2, op1). Les transposées doivent respecter O i.op1.t(op2,op1) = O i.op2.t(op1,op2) Modèle puissant mais pas général Définir les fonctions «Transpose» pour tous les couples d opérations Modèles de transactions avancés - 89 Réconciliation dans Cassandra (1) Modèles de transactions avancés - 91 Réplication dans Cassandra Paramètres R: nb de replicas lus W: nb de replicas écrits N: nb de réplicas Quorum Q = N/2 + 1 Différents choix possibles Pour R (resp. W) = 1, on récupère la 1 ère réponse W + R > N consistency R=1, W=N (ROWA) R=N, W=1 R=Q, W=Q Modèles de transactions avancés - 90 Réconciliation dans Cassandra (2) Weak consistency Read réparés après l envoi de la réponse Strong consistency Read réparés avant l envoi de la réponse Modèles de transactions avancés - 92