Bases de donnes reparties Dfinition Base de donnes

Bases de données reparties

Définition ¡ Base de données reparties? l Est une BD stockée sur plusieurs sites(machine +BD locale) connectes par un réseau. Logiquement reliées ¡ Physiquement distribuées ¡

Logiquement reliées ¡ Les applications voient les données comme une seule BD indépendamment de son emplacement physique Apps. Requêtes BD logique Computer 1 R 1, R 2 Computer 2 R 3 Vue logique Computer 3 Emplacement physique R 4, R 5

Physiquement distribuées ¡ La BD est placée sur différentes machines d’un réseau. Computer 1 R 1, R 2 Computer 2 R 3 Computer 3 Emplacement physique R 4, R 5

Problématique ¡ Les pressions pour la distribution : l l l Il devient impératif de décentraliser l’information (cas des multinationales), Augmentation du volume de l’information (14 fois de 1990 à 2000), Augmentation du volume des transactions (10 fois dans les 5 prochaines années).

¡ Pour améliorer le débit des E/Ss : l l l ¡ Partitionnement des données, Accès parallèle aux données, Utiliser plusieurs noeuds (avec un bon coût/ performance), et les faire communiquer par un réseau. Les BDRs se sont développées, grâce au progrès technologiques réalisés au niveau de l’infrastructure réseau et des postes de travail.

Objectifs 1. Transparence pour l’utilisateur 2. Autonomie de chaque site 3. Absence de site privilégié 4. Continuité de service 5. Transparence vis à vis de la localisation des données 6. Transparence vis à vis de la fragmentation 7. Transparence vis à vis de la réplication 8. Traitement des requêtes distribuées 9. Indépendance vis à vis du matériel 10. Indépendance vis à vis du système d’exploitation 11. Indépendance vis à vis du réseau 12. indépendance vis à vis du SGBD

Problèmes à surmonter 1. Coût : la distribution entraîne des coûts supplémentaires en terme de communication, et en gestion des communications (–hardware et software à installer pour gérer les communications et la distribution). 2. Problème de concurrence. 3. Sécurité : la sécurité est un problème plus complexe dans le cas des bases de données réparties que dans le cas des bases de données centralisées.

Objectives ¡ ¡ ¡ Permet aux utilisateurs de partager des données géographiquement reparties. Besoin de décentralisation des organisations, critères économiques Avantages ¡ ¡ Partage des données Fiabilité, disponibilité des données Accroissement de la vitesse de traitement Inconvénients ¡ ¡ ¡ Complexité des SGBDs Risque d'erreurs + important Surcoût du traitement du à la communication inter-sites

SGBD Reparti ¡ ¡ Un SGBD reparti assure la gestion d'une bd repartie Objectifs l Exécution des transactions - locales : accès aux données sur site - globales : accès sur plusieurs sites l Définition : données locales/réparties Cohérence des données Contrôle de concurrence Reprise après panne Optimisation de question Indépendance des applications - machine - système d'exploitation - protocole réseau - système de gestion de bases de données - localisation des données l l l

Conception des BDs reparties

Deux approches l Descendante : Top-down (du centralisée au distribuée) l Ascendante Bottom-up ( a partir de SGBDs existants vers des vues intégrées)

Architecture d’une BDR

¡ ¡ La répartition d'une base de donnée intervient dans les trois niveaux de son architecture en plus de la répartition physique des données : Niveau externe: les vues sont distribuées sur les sites utilisateurs. Niveau conceptuel: le schéma conceptuel des données est associé, par l'intermédiaire du schéma de répartition (lui même décomposé en un schéma de fragmentation et un schéma d'allocation), aux schémas locaux qui sont réparties sur plusieurs sites, les sites physiques. Niveau interne: le schéma interne global n'a pas d'existence réelle mais fait place à des schémas internes locaux répartis sur différents sites.

Approche descendante ¡ On commence par définir un schéma global de la base de données répartie (description globale et unifiée de toutes les données de la BDR). Puis, on le distribue sur les différents sites en des schémas locaux. ¡ Pour déterminer les schémas locaux, on peut utiliser plusieurs méthodes: - Stocker une relation sur un seul site - La réplication - La fragmentation - Réplication + fragmentation

Réplication ¡ Copie de chaque relation sur plusieurs site. ¡ Réplication complète= copie sur tous les sites. Ø Avantages Ø • Disponibilité des données. • Augmentation du parallélisme • Diminution du coût imposé par les transmissions Inconvénients • Difficulté d’assurer la cohérence des différentes copies. • Propagation des mises à jour.

Fragmentation ¡ Elle consiste à découper les relations en sous-relations appelées fragments. ¡ La répartition se fait donc en deux étapes: la fragmentation et l’allocation de ces fragments aux sites intéressés. Ø Pourquoi fragmenter? Ø • Généralement les applications utilisent des sous-ensembles de relations. • Une relation entière peut représenter une unité de distribution très grande • Utilisation de petits fragments permet de faire tourner plus d’un processus simultanément. Comment fragmenter? • On distingue trois possibilité de fragmentation: • Fragmentation Horizontale • Fragmentation Verticale • Fragmentation Hybride

Fragmentations correctes? ¡ Complitude: R fragmentée en R 1 R 2 , …, Rn chaque élément se trouvant dans R doit figurer dans au moins un fragment Ri l ¡ Reconstruction: soit la relation R , F= {R 1, R 2, . , Rn} l ¡ Évite les pertes de données pendant la fragmentation il est toujours possible de reconstruire R en appliquant des opérations sur F Disjonction – fragments de R contient des sous ensembles de R. Ri Rj= . l Garantit l’absence de redondance

Fragmentation horizontale ¡ Les fragmentation horizontale concerne les données. ¡ Chaque fragment représente un ensemble de tuples. ¡ Pour fragmenter, on a besoin d’information sur la BD (schéma global, …) et les applications (requêtes utilisées, …). ¡ Les fragments sont définis par des opérations de sélection sur les relations.

Exemple ALLOC EMP ENO PNO RESP DUR TITLE Elec. Eng. E 1 P 1 Mngr 12 E 2 P 1 Anal. 24 E 2 M. Smith Syst. Anal. E 2 P 2 Anal. 6 E 3 A. Lee Mech. Eng. E 3 P 3 Cons. 10 E 4 J. Miller Programmer E 3 P 4 Eng. 48 E 5 B. Casey Syst. Anal. E 4 P 2 Prog. 18 E 6 L. Chu Elect. Eng. E 5 P 2 Mngr 24 E 7 R. Davis Mech. Eng. E 6 P 4 Mngr 48 E 8 J. Jones Syst. Anal. ENO EName E 1 J. Doe

Exemple Proj PNO PName Sal Budget Location P 1 Bioinfo 500000 Lausanne P 2 ELearn. 300000 Rio P 3 Plasma 100000 Geneva P 4 Aircraft 150000 Lausanne Title Salary Elec. Eng. 40000 Syst. Anal. 34000 Mech. Eng. 27000 Programmer 24000

Exemple de fragmentation horizontale Proj PNO PName Budget Location 1 P 1 Bioinfo 500000 Lausanne P 2 ELearn. 300000 Rio Budget Location Proj PNO PName 2 P 3 Plasma 100000 Geneva P 4 Aircraft 150000 Lausanne Relations with BUDGET > 200. 000 go into Proj 1 and the rest goes into Proj 2. Proj 1= (budget>200. 000) Proj 2= (budget ≤ 200. 000) Proj

¡ La reconstruction de la relation est définie par l’union des fragments. ¡ Les requêtes de l’utilisateur incluent des prédicats plus complexes qui sont des combinaison des prédicats simples. Puisqu’on peut toujours transformer une expression booléenne en une forme normale conjonctive, on se base sur les prédicats conjonctives pour fragmenter.

Comment? ¡ Comment obtenir des fragments disjoints et assurer la reconstruction ? l l l Génération automatique Souvent « manuelle » par l ’administrateur. Différentes méthodologies selon le type de fragmentation.

Analyse fragmentation horizontale ¡ Commencer avec les conditions de sélection fréquentes (FAQ) l Extraire des requêtes les conditions de sélections: ¡ l A < 10, A > 5, Ville = Tunis, Ville = Sfax On obtient un ensemble : C={c 1, c 2, . . . cn} des conditions élémentaires (ce).

Fragmentation Horizontal ¡ Construire l’ensemble des conjonctions de ce (cc) suivant : l l Simplifier chaque cc ! Supprimer les cc tjr fausses

Exemple ¡ ¡ ¡ ¡ A < 10, A > 5, Ville = Tunis, Ville = Sfax A < 10, A > 5, Ville = Tunis, Ville != Sfax A < 10, A > 5, Ville != Tunis, Ville != Sfax A < 10, A <= 5, Ville != Tunis, Ville != Sfax A >= 10, A > 5, Ville = Tunis, Ville = Sfax ¡ A >=10, A > 5, Ville = Tunis, Ville != Sfax ¡ A >= 10, A > 5, Ville != Tunis, Ville !=Sfax ¡ A >= 10, A <= 5, Ville = Tunis, Ville =Sfax ¡ A >=10, A <= 5, Ville = Tunis, Ville !=Sfax ¡ A >= 10, A <= 5, Ville != Tunis, Ville = Sfax ¡ A >= 10, A <= 5, Ville != Tunis, Ville != Sfax ¡

Éliminer les inutiles. . . Conditions non satisfiables ¡ Connaissance des contraintes d’intégrité, e. g; ville soit Tunis, soit Sfax ¡ l l l A < 10, A > 5, Ville = Tunis, Ville != Sfax A < 10, A > 5, Ville != Tunis, Ville = Sfax A < 10, A <= 5, Ville = Tunis, Ville != Sfax A < 10, A <= 5, Ville != Tunis, Ville = Sfax A >=10, A > 5, Ville = Tunis, Ville != Sfax A >= 10, A > 5, Ville != Tunis, Ville = Sfax.

Fragments Finaux Regrouper les conditions sur un même attribut ¡ 5 < A < 10, Ville = Tunis ¡ 5 < A < 10, Ville = Sfax ¡ A <= 5, Ville = Tunis ¡ A <= 5, Ville = Sfax ¡ A >=10, Ville = Tunis ¡ A >= 10, Ville = Sfax ¡

Propriétés de la fragmentation ¡ Complétude : l ¡ Disjonction : l ¡ tout n-uplet t vérifie une des ce et nous avons éliminé seulement les cc impossibles Supposons t valide deux cc (cc 1 et cc 2) alors : et donc t satisfait ci et $ci , contradiction !!

Bonne propriétés ¡ Obtenir une partition de l’ensemble de nuplets telle que : pour tout B de la partition, deux n-uplets de B aient la même probabilité d’être accédés par toute application/requête importante

Fragmentation verticale ¡ La fragmentation concerne le schéma. ¡ Les fragments sont définis par des opérations de projection. ¡ La reconstruction est définie par jointure. ¡ La clé doit être répétée dans chaque fragment. ¡ Pour appliquer la fragmentation verticale, il existe deux possibilités: ¡ Clustering: affecter chaque attribut à un fragment, puis à chaque étape fusionner certains fragments et s’arrêter lors de la satisfaction de certaines conditions. ¡ Splitting: on part de la relations, puis on décide de la partitionner en des fragments en se basant sur des informations concernant les applications et les attributs.

Exemple de fragmentation verticale Proj PNO Budget 1 P 1 500000 P 2 300000 P 3 1000000 P 4 150000 Proj PNO PName Location 2 P 1 Bioinfo Lausanne P 2 ELearn. Rio P 3 Plasma Geneva P 4 Aircraft Lausanne

Matrice d’utilisation Ø Soit la relation Projet(Pnum, Pnom, Budget, Loc) et soit l’ensemble de requêtes: q 1= budget d’un projet étant donnée son numéro. q 2= nom et budget de tous les projets. q 3= nom des projets d’une ville. q 4= budget total des projets d’une ville Ø La matrice d’utilisation est définie comme suit: Ut(qi, Aj)=1 si la requête qi utilise l’attribut Aj et Ut(qi, Aj)= 0 sinon.

Exemple A 1 A 2 A 3 A 4 q 1 1 0 q 2 0 1 1 0 q 3 0 1 q 4 0 0 1 1

Matrice d’affinité Ø Refs(qk) pour deux attributs (Ai, Aj) = nombre d’accès effectués par une exécution de qk (sur le site s) aux attributs Ai et Aj. Ø Accs(qk) est la fréquence d’exécution de qk sur le site s (mesurée pendant une certaine période). - La matrice d’affinité est définie comme suit: Aff(Ai, Aj)= k/Ut(qk, Ai)=1 et Ut(qk, Aj)=1 site s Refs(qk)*Accs(q. K)

Exemple ¡ Supposons : Refs( qk ) = 1, quelques soient s et k ¡ Les accès suivants (3 sites): l Acc 1(q 1)=15 Acc 2(q 1) = 20 Acc 3(q 1) = 10 l Acc 1(q 2)=5 Acc 2(q 2) = 0 Acc 3(q 2) = 0 l Acc 1(q 3)=25 Acc 2(q 3) = 25 Acc 3(q 3) = 25 l Acc 1(q 4)= 3 Acc 2(q 4) = 0 Acc 3(q 4) = 0 l l Aff(A 1, A 3) = K=1 s Accs(qk) = Acc 1(q 1) +Acc 2(q 1) +Acc 3(q 1) = 45

Exemple A 1 A 2 A 3 A 4 A 1 45 0 0 A 2 0 80 5 A 3 45 5 A 4 0 75 3 45 53 A 1 A 3 A 2 A 4 A 1 45 45 0 0 75 A 3 45 53 5 3 3 A 2 0 5 80 75 78 A 4 0 3 75 78 ØRegroupement des attributs ayant une haute affinité

Partitionnement Trouver un point dans la matrice pour créer deux ensembles d’attributs: Attr. Haut(AH) et Attr. Bas(AB). - AR(qi)={Aj/Ut(qi, Aj)=1} - RH={qi/AR(qi) AH} - RB={qi/AR(qi) AB} - Autres =Q- {RH RB} - D’après notre exemple, on obtient: Q ={q 1, q 2, q 3, q 4} AH={A 1, A 3} AB={A 2, A 4} RH= {q 1} RB= {q 3} Autres= {q 2, q 4}

Objectives - Maximiser les accès à un seul fragment. - Minimiser les accès aux deux fragments. ¡ Total RH= qk RH site s Refs(qk)*Accs(q. K)=45. ¡ Total RB= qk RB site s Refs(qk)*Accs(q. K)=75. ¡ Total. Autres= qk autres site s Refs(qk)*Accs(q. K)=8. ¡ Trouver un point dans la matrice pour créer deux ensembles d’attributs AH et AB tels que : z=(Total. RH*Total. RB)-Total. Autres 2 est maximisé. ¡ La relation projet est partitionné en deux fragments: Projet 1(Pnum, Budget). Projet 2(Pnum, Pnom, Loc). ¡ ¡ ¡ La duplication de la clé permet de garantir la construction. Si beaucoup d’attributs alors il est peut être nécessaire de trouver plusieurs points dans la matrice. Utiliser plutôt une approche récursive : partir de deux groups AH et AB et raffiner.

Fragmentation Hybride ¡ Fragmentation horizontale suivit de la fragmentation verticale ou vice-versa R horizontale R 1 R 2 Verticale R 11 R 12 R 21 R 22 R 23

Allocation ¡ Supposons qu’on dispose d’un ensemble de fragments F={F 1, F 2, …Fn} et d’un réseau constitué d’un ensemble de sites S={S 1, S 2, …Sn}. ¡ Une distribution optimale de F sur S est définie en considérant deux mesures: Ø Un coût minimal La fonction coût est une combinaison d’un ensemble de coûts: - Coût de stockage de chaque fragment Fi sur un site Sj. - Coût de modification de Fi sur un site Sj. - Coût d’interrogation de Fi sur un site Sj. - Coût de communication. Ø Une meilleure performance - Minimiser le temps de réponse.

Résumé Relation Globale FRAGMENTATION Fragments ALLOCATION Relations locales

Approche Ascendante (bottom up design) ¡ On dispose de différentes bases de données (les schémas locaux) et on veut les intégrer pour construire un schéma global. ¡ L’intégration des bases de données peut être effectuée en deux étapes: la traduction des schémas et l’intégration des schémas. SCG Intégrateur Traducteur 1 BD 1 Traducteur 2 BD 2 Traducteur n BDn

Étape de Traduction ¡ Transformer le schéma local en un autre schéma. ¡ Exemple: transformer un schéma en modèle réseau en un schéma en modèle relationnel Ø Schémas intermédiaires Pré-intégration - Identification des éléments reliés (e. g. domaines équivalents) et établissement des règles de conversion (e. g. 1 inch =2. 54 cm). Ø Comparaison - Identification des conflits de noms (synonymes, homonymes) et des conflits structurels(clé, dépendances, …). Ø Conformance - Résolution des conflits de noms (renommage) et des conflits structurels (changements des clés…) Ø Fusion et Restructuration - Fusion des schémas intermédiaires et restructuration pour créer un schéma intégré optimal. .

Traitement reparti ¡ Objectifs -> Minimiser les accès disque -> Minimiser le temps CPU -> Minimiser la transmission réseau -> Exploiter le parallélisme

Étapes de traitement Décomposition de la requête utilisateur: l l Elle consiste à transformer la requête utilisateur en une requête de l’algèbre relationnelle. Décomposition: Normalisation, analyse, élimination de redondance et réécriture. l Normalisation ¡ ¡ ¡ Transformer la requête en une forme permettant de faciliter son traitement. On peut distinguer deux formes: forme normale conjonctive et forme normale disjonctive. Cette transformation utilise les règles d’équivalence suivantes:

o p 1 p 2 p 1. ¡ p 1 p 2 p 1. ¡ p 1 (p 2 p 3) (p 1 p 2) p 3. ¡ p 1 (p 2 p 3) (p 1 p 2) p 3. ¡ p 1 (p 2 p 3) (p 1 p 2) (p 1 p 3). ¡ p 1 (p 2 p 3) (p 1 p 2) (p 1 p 3). ¡ (p 1 p 2 ) p 1 p 2 ¡ (p 1 p 2 ) p 1 p 2 ¡ ( p) p ¡ Analyse ¡ L’analyse de la requête permet d’identifier les requêtes incorrectes qui doivent être rejetées.

Décomposition de la requête ¡ Les raisons principales de rejection d’une requête sont : soit la requête est type incorrect soit elle est sémantiquement incorrecte. ¡ Exemple Soit la requête suivante: SELECT Enum FROM Employe WHERE Enom>200 Cette requête est incorrecte car la condition « >200 » est incompatible avec le type varchar de l’attribut Enom. ¡ Il est possible d’identifier les requêtes sémantiquement incorrectes si ces requêtes ne contiennent pas de disjonction et de négation. ¡ La requête est représentée par un graphe, nommé graphe de requête ou graphe de connexion. Si le graphe obtenu est non connexe alors la requête est sémantiquement incorrecte.

Décomposition de la requête Exemple: Soit la base de données suivante: E (Enum, Enom, Titre, Salaire) /* E est la relation employé */ P (Pnum, Pnom, Budget) /* P est la relation projet */ EP(Enum, Pnum, Resp, Dur) Soit la requête: SELECT Enom, Resp FROM E, P, EP WHERE E. Enum = EP. Enum and Pnom= « maintenance » and Dur 36 and Titre = « programmeur »

Décomposition de la requête Dur 36 Pnom= « maintenance » EP E. Enum= EP. Enum Resp Titre= « progrmmeur » ¡ E P Résultat Enom Cette requête est incorrecte car elle manque une condition de jointure: P. Pnum = EP. Pnum

Élimination de la redondance ¡ Les redondances peuvent être éliminées en simplifiant la requête par les règles suivantes l p p p. l p true p. l p false. l p true. l p p false l p p true l p 1 (p 1 p 2) p 1

Réécriture ¡ Réécrire la requête en algèbre relationnelle ¡ La requête en algèbre relationnelle peut être représentée par un arbre. ¡ Exemple: Soit la requête: SELECT Enom FROM E, P, EP WHERE E. Enum = EP. Enum and EP. Pnum= P. Pnum and Pnom = « maintenance » and (Dur = 12 OR Dur = 24) L' arbre de la requête en algèbre relationnelle est:

Enom ¡ ¡ Dur=12 OR Dur=24 En appliquant les règles de transformation, on peut obtenir plusieurs arbres équivalents. Pnom= «maintenace » Parmi les règles de transformation, on peut citer les règles suivantes: pnum Soit les relations R, S et T: Enum - R S S R - (R S) T R (S T) - A’( A’’(R)) A’(R) si A’ A’’. - P 1(A 1)( P 2(A 2) (R)) P 1(A 1) P 2(A 2)(R). P EP E

Localisation des données • Cette étape permet de translater une requête en algèbre relationnelle exprimée par le schéma global de la base de données en une requête exprimée par les schémas locaux (l’ensemble des fragments) • Les requêtes utilisant des relations fragmentées horizontalement l Exemple: On considère que la relation employé (E) est fragmenté comme suit: E 1= Enum 3(E). E 2= 3<Enum<6(E). E 3= Enum>6(E). Enum=5 La relation est obtenue par l’union E 1 E 2 E 3 Soit la requête: SELECT * FROM E WHERE Enum=5. E 1 E 3 E 2

Localisation des Données ¡ Cette requête peut être simplifiée requête réduite. ¡ Les règles de réduction permettent d’identifier les fragments générant des relations vides. Ø Sélection: on considère une relation R fragmentée horizontalement en R 1, R 2, …Rn tel que Rj= Pj (R). Règle 1: Pi (Rj)= si x un tuple de R : (Pi(x) Pj(x)) Pi et Pj sont des prédicats de sélection. Exemple: on considère la requête: SELECT * FROM E WHERE Enum=5. D’après la règle 1, si on applique le prédicat de sélection « Enum=5 » pour les fragments E 1 et E 3 on obtient des relation vides. Donc la requête est réduite comme suit Enum=5 E 2

Jointure: on peut détecter les jointures inutiles en se basant sur la règle suivante: Règle 2: Ri Rj= si x un tuple de Rj y un tuple de Ri : (Pi(x) Pj(y)) Ri et Rj sont deux fragments définis respectivement par les prédicats Pi et Pj Exemple: on considère la requête: SELECT * FROM E , EP WHERE E. Enum=EP. Enum On considère que EP est fragmentée comme suit: EP 1= Enum 3(EP) EP 2= Enum>3(EP) Enum E 1 E 2 E 3 EP 1 Requête Générique EP 2 E 1 EP 1 E 2 EP 2 Requête Réduite E 3 EP 2

Les requêtes utilisant des relations fragmentées verticalement On considère que la relation Employé E est fragmentée verticalement comme suit: E 1= Enum, Enom( E ) E 2= Enum, Titre( E ) ¡ La relation E est reconstruite par une opération de jointure. E= E 1 E 2 ¡ Les requêtes utilisant des relations fragmentées verticalement peuvent être réduites en éliminant les opérations inutiles. Pour ce faire, on utilise la règle suivante: Règle 3: on pose Ri = A’( R ) D( Ri ) est inutile si l’ensemble des attributs D intersection A’ égale au vide

Exemple: Soit la requête: SELECT Enom FROM E Enom Enum Enom E 1 E 2 E 1 Requête Générique Requête réduite

Validation des Transactions réparties ¡ OBJECTIF l ¡ EXEMPLE l l l ¡ Garantir que toutes les mises à jour d'une transaction sont exécutées sur tous les sites ou qu'aucune ne l'est. Transfert de la somme X du compte A vers le compte B DEBUT ¡ site 1: A = A - X ¡ site 2: B = B + X PANNE --> INCOHERENCE DONNEES FIN PROBLEME l Le contrôle est réparti : chaque site peut décider de valider ou d’annuler. . .

Commit en 2 Phases ¡ Principe l l l ¡ Coordinateur : l ¡ Diviser la commande COMMIT en deux phases Phase 1 : ¡ Préparer à écrire les résultats des mises à jour dans la BD ¡ Centralisation du contrôle Phase 2 : ¡ Écrire ces résultats dans la BD Le composant système d'un site qui applique le protocole Participant : l Le composant système d'un autre site qui participe dans l'exécution de la transaction

Protocole C/S ¡ 1. PREPARER l ¡ 2 a. SUCCES : COMMETTRE l ¡ Tous les participants effectuent leur validation sur ordre du client. 2 b. ECHEC : ABORT l ¡ Le coordinateur demande aux autres sites s’ils sont prêts à commettre leurs mises à jour. Si un participant n’est pas prêt, le coordinateur demande à tout les autres sites de défaire la transaction. REMARQUE l Le protocole nécessite la journalisation des mises à jour préparées et des états des transactions dans un journal local à chaque participant.

Cas Favorable SITE COORDINATEUR SITE PARTICIPANT 2 SITE PARTICIPANT 1 PREPARE OK COMMIT ACK

Cas Défavorable (1) SITE COORDINATEUR SITE PARTICIPANT 2 SITE PARTICIPANT 1 PREPARE OK KO ABORT ACK

Cas Défavorable (2) SITE COORDINATEUR SITE PARTICIPANT 2 SITE PARTICIPANT 1 PREPARE OK COMMIT ACK STATUS COMMIT ACK

Commit distribué ou centralisé ¡ Validation à deux phases centralisée Prepare ¡ OK Commit OK Possibilité de diffuser la réponse au PREPARE l chaque site peut décider localement dans un réseau sans perte OK Prepare

Transitions d'Etats Initial CCommit/Prepare Wait Vote. KO/GAbort Vote. OK/GCommit Initial Commit Prepare/Vote. OK COORDINATEUR Ready GAbort/Ack Abort GCommit/Ack Commit PARTICIPANT

Transactions bloquées ¡ Que faire en cas de doute ? l Demander l’état aux autres transactions : STATUS conservation des états nécessaires ¡ message supplémentaire ¡ l Forcer la transaction locale : ABORT toute transaction annulée peut être ignorée ¡ cohérence garantie avec un réseau sans perte de message ¡ l Forcer la transaction locale : COMMIT toute transaction commise peut être ignorée ¡ non garantie de cohérence avec le coordinateur ¡

Commit en 3 Phases Initial CCommit/Prepare ¡ Inconvénient du commit à 2 phases l l ¡ en cas de time-out en état “Prêt”, le participant est bloqué le commit à 3 phases permet d’éviter les blocages Messages du commit à 3 phases l l Vote. KO/GAbort Prepare, Prepare to Commit, Global-Abort. Wait Vote. OK/PréCommit Abort PréCommit PréOK/GCommit Initial Prepare/Vote. OK GAbort/Ack Abort Ready PréCommit/PréOK PréCommit GCommit/Ack Commit

Protocole arborescent TP Coordinateur global ¡ ¡ TP est le standard proposé par l’ISO dans le cadre OSI Protocole arborescent l Tout participant peut déclancher une sous-transaction l Un responsable de la validation est choisi l Un coordinateur est responsable de ses participants pour la phase 1 ¡ collecte les PREPARE ¡ demande la validation l Le point de validation est responsable de la phase 2 ¡ envoie les COMMIT Coordinateur local Point de validation (Noeud critique)