ARCHITECTURES DES SGBDOO

ARCHITECTURES DES SGBDOO PLAN Quelques rappels Objectifs des SGBD Applications Architectures client-serveur & SGBDOO Rappel des Architectures Réseaux locaux Topologies d'interconnexion Protocoles et standard réseaux Architecture d'un SGBOO Architecture Fonctionnelle Architecture Opérationnelle Le marché des SGBD

Quelques Rappels Objectifs des SGBD INDÉPENDANCE PROGRAMMES/DONNÉES Indépendance physique Indépendance logique ACCÉS PAR DES LANGAGES ASSERTIONNELS Recherche (le quoi et non le comment) Insertion (en groupes, calculées) Mise à jour (basée sur la recherche) EFFICACITÉ DES ACCÈS Temps de réponse & débit global Benchmarks TPC/A, B, C, D ==> TPS, CPM

Quelques Rappels Objectifs des SGBD SUPPORT DE TRANSACTIONS ACID Atomique (tout ou rien) Cohérente (respect de l'intégrité) Isolée (non visibilité des mises à jour non commise) Durable (garantie des mises à jour commises) PARTAGEABILITÉ ET SÉCURITE DES DONNÉES Simultanéité lecture/écriture maximum Accès transactionnels & décisionnels Confidentialité (authentification, droits d'accès, cryptage) Restauration après pannes (journaux, sauvegardes)

Quelques Rappels Objectifs des SGBD CONCEPTION FACILITÉE DES APPLICATIONS Conception visuelle des BD (diagrammes E/R, objets) Conception des traitements (diagrammes de flux entre modules) Dictionnaire de données (objets BD, graphiques, applicatifs) ADMINISTRATION SYSTÈME FACILITÉE Outils d'audit & de tunning Visualisation des plans d accès Élaboration de statistiques

Quelques Rappels Applications Caractéristiques OLTP OLAP Opérations typiques Maj Analyse Type d'accès Lect/Ecr Lecture Niveau d'analyse Elémentaire Global Ecrans Fixe Interactif Quantité d'info échangée Faible Importante Orientation Record Multi-dim. Taille BD 100 MB-GB 1GB - TB Ancienneté des données Récente Récente Historique Future

Quelques Rappels Architecture ANSI/X3/SPARC Architecture Conceptuelle Admin. BD Admin. Entreprise Processeur de schéma Conceptuel Admin. Application Processeur de schéma Interne DICTIONNAIRE Processeur de schéma Externe Transformateur Interne Stockage Transformateur Conceptuel Interne Transformateur Externe Conceptuel Système d E/S Programme d application Programmeur. d application

ARCHITECTURES DES SGBDOO PLAN Quelques rappels Objectifs des SGBD Applications Architectures client-serveur & SGBDOO Rappel : Quelques notions de réseaux Réseaux locaux Topologies d'interconnexion Protocoles et standard réseaux Architecture Client-Serveurs Architecture d'un SGBOO Fonctionnalités d'un SGBDOO Architecture Fonctionnelle Architecture Opérationnelle Le marché des SGBD

Architecture Client-Serveurs & SGBDOO Rappel : Quelques notions de réseaux Réseau local : Un groupe de noeuds Ordinateurs (Clients ou serveurs) Services (Fichiers, Noms, Messages, Logiciels) Aire géographique limitée (1 Bâtiment ou quelques.) Serveur de Fichier Station1 Station2 StationN Réseau Local

Architecture Client-Serveurs & SGBDOO Rappel : Quelques notions de réseaux Topologies d'interconnexions : Etoile Anneau BUS

Architecture Client-Serveurs & SGBDOO Rappel : Quelques notions de réseaux Topologies d'interconnexions : Point à Point Multi-Point Hiérarchique

Architecture Client-Serveurs & SGBDOO Rappel : Quelques notions de réseaux Protocoles et Standards Interconnexion (COUCHES ISO ) Transport de Données Echange de méssage Contrôle Systèmes d'exploitation distribués (NFS, NetWare)

Architecture Client-Serveurs & SGBDOO Architecture Client-Serveur Définition modèle d'architecture applicative où les programmes sont répartis entre processus clients Processus serveurs communication par des requêtes / réponses. Une répartition hiérarchique des fonctions données sur le serveur partagées entre N clients interfaces graphiques sur la station de travail personnelle communication par des protocoles standardisés distribution des programmes applicatifs afin de minimiser les coûts Quelle est la meilleure distribution des fonctions?

Architecture Client-Serveurs & SGBDOO Architecture Client-Serveur Pourquoi le C/S? Évolution des besoins de l'entreprise Augmentation de productivité, rapidité de réactivité souhaitée Utilisation des micros assurant flexibilité et faibles coûts Besoin de décisionnel et transactionnel sur gros volumes Évolution des technologies Systèmes ouverts permettant l'usage de standards Environnements de développement graphiques Explosion de la puissance des micros et des serveurs (parallèles) Solutions techniques séduisantes Les données partagées enfin accessibles simplement Mise en commun des services (règles de gestion, procédures) Gestion de transactions et fiabilité au niveau du serveur

Architecture Client-Serveurs & SGBDOO Architecture Client-Serveur Architecture 1e génération SERVEUR SGBD NT, UNIX, NOVELL GCOS, VMS, MVS règles Données REQUETE RESULTAT Windows NT UNIX APPLICATION APPLICATIONS CLIENTS APPLICATIONS

Architecture Client-Serveurs & SGBDOO Architecture Client-Serveur Le C/S de 2e génération Procédure stockée Procédure accomplissant une fonction de service sur les données Exemple : Entrée ou sortie de stock Architecture orientée services plutôt que requêtes Distribution des traitements Peut être automatisée Évolution et passage à l'échelle Possibilité de serveurs multiples, avec redondances Possibilité de données privées sur les clients Requêtes de services Application Outil Applicatif Outil de connectabilité Protocole Réseau Serveur BD Protocole Réseau Outil de connectabilité base de données Résultats Procédures Stockées Client Serveur

Architecture Client-Serveurs & SGBDOO Architecture Client-Serveur Intérêt du C/S de 2e génération Réduction des transferts réseaux non nécessité de monter les données dans le client pour les modifier appel de services plus compact Distribution automatique des applications développement sur le poste de travail partitionnement par tirer-déposer (drag & drop) Simplification des outils de développement principe de la fenêtre unique modélisation uniforme des objets applicatifs invisibilité du modèle de données à l'extérieur du serveur

Architecture Client-Serveurs & SGBDOO Architecture Client-Serveur Faiblesses du client-serveur Une mise en œuvre difficile nécessité de spécialistes réseaux, BD, PC des outils hétérogènes et peu portables les évolutions sont difficiles Des arguments contre? accroissement des coûts (40%?), notamment pour la maintenance des interfaces graphiques hétérogènes (Windows, Motif, Mac) des difficultés de passage à l'échelle (dimensionnement, performance)

Architecture Client-Serveurs & SGBDOO Architecture Client-Serveur Vers le C/S Universel (3e géné.) Intégration du Web et du client-serveur navigateur à présentation standard pour le client possibilité de petites applications (applets) sur le client très grande portabilité (Réseau Privé Virtuel, Intranet, Internet) Architecture à 3 strates (3-tiered) Base de données avec procédures stockées Services applicatifs partagés Présentation hypertexte multimédia avec applets Support de l'hypermédia types de données variées et extensibles (texte, image, vidéo) hypertexte et navigation entre documents et applications

Architecture Client-Serveurs & SGBDOO Architecture Client-Serveur Bilan C/S Les SGBD fonctionnent tous en C/S Trois niveaux de fonctions distinguées : données (SGBD) application (L4G) présentation (Web, Windows, Motif) Questions? Alors, trois machines et un moniteur transactionnel?

Architecture Client-Serveurs & SGBDOO ARCHITECTURES DES SGBDOO PLAN Quelques rappels Objectifs des SGBD Applications Architectures client-serveur & SGBDOO Rappel : Quelques notions de réseaux Réseaux locaux Topologies d'interconnexion Protocoles et standard réseaux Architecture Client-Serveurs Architecture d'un SGBOO Rappel : Fonctionnalités d'un SGBDOO Architecture Fonctionnelle Architecture Opérationnelle Le marché des SGBD

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Rappel : Fonctionnalités SGBDOO The Object-Oriented Database System Manifesto Atkinson, Bancilhon, Dewitt, Ditrich, Maier, Zdonick ( DOOD'89) Fonctionnalités BD obligatoires : la persistance la concurrence la fiabilité la facilité d'interrogation Fonctionnalités BD optionnelles : la distribution les modèles de transaction évolués les versions

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Rappel : Fonctionnalités SGBDOO Fonctionnalités objets obligatoires : les objets atomiques et complexes l'identité d'objets l'héritage simple le polymorphisme (surcharge) Fonctionnalités objets optionnelles : l'héritage multiple les messages d'exception

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Architecture d'un SGBDOO comprend : Une architecture fonctionnelle Présente 3 différents niveaux de fonctionnalités du système Couche OUTILS Couche Langage Langage de définition et de programmation Interfaces avec d'autres systèmes (Relationnel.) Gestions des Objets L'architecture fonctionnelle est similaire sur différents SGBDOO Une architecture opérationnelle Réalise l'architecture fonctionnelle dans un environnement matériel Présente la distribution des fonctionnalités d'un SGBDOO entre le client et le(s) serveurs

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Architecture Fonctionnelle d'un SGBDOO Architecture fonctionnelle type : Editeur de classes Manipulateur d objets Outils Interactifs Bibliothèques graphiques Débogueur, éditeur OQL = Object Query Language LOO Persist. OQL ODL ODL = Object Defintion Language LOO = Langage Orienté Objet Gérant d'objets Persistance Concurrence Identification Fiabilité Accès Sécurité

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Architecture Opérationnelle d'un SGBDOO Problèmes : comment distribuer les fonctions du SGBDO? quel protocole de communication utiliser? quelle organisation en processus et tâches répartis? Constatation environnement de stations en réseau très fréquent puissance croissante des postes de travail le débit réseau n'est plus un goulot (100 Mbit/sec.) Conclusion puissance de traitement importante au niveau des clients une grande partie des fonctions peut résider à ce niveau

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Architecture Opérationnelle Simplifiée Application Programme utilisateur Compilation Objets Fichiers Verrous Journal Pages Principales fonctions à distribuer entre Clients et Serveurs

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Serveur d'objets Application Cache objets Verrous Journal Cache objets objets Fichiers et index Unité de transfert : Un objet ou groupe d'objets Client léger Fonctions BD sur le serveur Centralisation qui favorise le contrôle d'intégrité sécurité Interface Client / Serveur Créer ou détruire un objet Lire ou écrire un objet Envoyer un message à un objet Cache pages

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Serveur de pages Application Objets actifs Recherche Fichiers et index Pages Verrous journaux Cache pages Unité de transfert : Une ou plusieurs pages Serveur allégé + de Fonctions BD sur le client Décentralisation qui complique le contrôle d'intégrité sécurité Caches pages dupliquées sur client et serveur Interface Client / Serveur Allouer ou désallouer les pages Lire ou écrire des pages pages Cache pages

Architecture Client-Serveurs & SGBDOO Serveur de méthodes Architecture SGBDOO Application Objets actifs Répartiteur de Messages Gestion d'objets Cache pages Remote Object Call ORB Application Objets actifs Répartiteur de Messages Gestion d'objets Cache pages

Architecture Client-Serveurs & SGBDOO Architecture SGBDOO Comparaisons Points forts Points faibles Serveur méthodes sur client ou serveur serveur centralisé d'objets concurrence niveau objet duplication de fonctions Serveur distribution de pages possible méthodes sur le serveur imposs. de pages serveur plus simple concurrence niv. objet difficile hétérogénéité difficile Serveur méthodes sur client ou serveur performances pour petits objets de transfert de messages standards peu bases de données méthodes système uniforme et extensible Corba et service BD?

Architecture Client-Serveurs & SGBDOO ARCHITECTURES DES SGBDOO PLAN Quelques rappels Objectifs des SGBD Applications Architectures client-serveur & SGBDOO Rappel : Quelques notions de réseaux Réseaux locaux Topologies d'interconnexion Protocoles et standard réseaux Architecture Client-Serveurs Architecture d'un SGBOO Rappel : Fonctionnalités d'un SGBDOO Architecture Fonctionnelle Architecture Opérationnelle Gestion de Transactions

Plan Gestion des Transactions Objectifs et bases Journaux et reprise PLAN Scénarios de reprise Modèles étendus de transaction Transactions réparties Moniteurs transactionnels Conclusions

Objectifs et bases Le transactionnel (OLTP) Opérations typiques mises à jour ponctuelles de ligne par des écrans prédéfinis, souvent répétitive, sur les données les plus récentes Exemple Benchmark TPC-A et TPC-B : débit / crédit sur une base de données bancaire TPC-A transactionnel et TPC-B avec traitement par lot Mesure le nombre de transactions par seconde (tps) et le coût par tps

La base TPC-A/B Objectifs et bases 1 100000 Agences Comptes Caissiers Historique 100 La base TPC-A/B Taille pour 10 terminaux, avec règle d'échelle ( scaling rule)

Objectifs et bases La transaction Débit-Crédit Begin-Transaction Update Account Set Balance = Balance + Delta Where AccountId = Aid ; Insert into History (Aid, Tid, Bid, Delta, TimeStamp) Update Teller Set Balance = Balance + Delta Where TellerId = Tid ; Update Branch Set Balance = Balance + Delta Where TellerId = Tid ; End-Transaction. 90 % doivent avoir un temps de réponse < 2 secondes Chaque terminal génère une transaction toute les 10s Performance = Nb transactions commises / Ellapse time

Objectifs et bases Cohabitation avec le décisionnel Les transactions doivent souvent cohabiter avec des requêtes décisionnelles, traitant un grand nombre de tuples en lecture Exemple : Moyenne des avoir des comptes par agence SELECT B.BranchId, AVG(C.Balance) FROM Branch B, Account C WHERE B.BrachId = C.BranchId GROUP BY B.BranchId ;

Objectifs et bases Les menaces Problèmes de concurrence pertes d opérations introduction d incohérences verrous mortels (deadlock) Panne de transaction erreur en cours d'exécution du programme applicatif nécessité de défaire les mises à jour effectuées Panne système reprise avec perte de la mémoire centrale toutes les transactions en cours doivent être défaites Panne disque perte de données de la base

Objectifs et bases Propriétés des transactions Atomicité Unité de cohérence : toutes les mises à jour doivent être effectuées ou aucune. Cohérence La transaction doit faire passer la base de donnée d'un état cohérent à un autre. Isolation Les résultats d'une transaction ne sont visibles aux autres transactions qu'une fois la transaction validée. Durabilité Les modifications d une transaction validée ne seront jamais perdue

Objectifs et bases Commit et Abort INTRODUCTION D ACTIONS ATOMIQUES Commit (fin avec succes) et Abort (fin avec echec) Ces actions s'effectuent en fin de transaction COMMIT Validation de la transaction Rend effectives toutes les mises à jour de la transaction ABORT Annulation de la transaction Défait toutes les mises à jour de la transaction

Objectifs et bases Schéma de transaction simple Fin avec succès ou échec Begin_Transaction update update... Commit ou Abort - Provoque l'intégration réelle des mises à jour dans la base - Relâche les verrous - Provoque l'annulation des mises à jour - Relâche les verrous - Reprend la transaction

Effet logique Update Update Objectifs et bases Mémoire de la transaction Commit Abort Bases de données Poubelle

Objectifs et bases Interface applicative API pour transaction simple Trid Begin (context*) Commit () Abort() Possibilité de points de sauvegarde : Savepoint Save() Rollback (savepoint) // savepoint = 0 ==> Abort Quelques interfaces supplémentaires ChainWork (context*) //Commit + Begin Trid Mytrid() Status(Trid) // Active, Aborting, Committing, Aborted, Committed

Plan Gestion des Transactions Objectifs et bases PLAN Journaux et reprise Scénarios de reprise Modèles étendus de transaction Transactions réparties Moniteurs transactionnels Conclusions

Journaux et Sauvegarde Journal des images avant Journal contenant les débuts de transactions, les valeurs d'enregistrement avant mises à jour, les fins de transactions (commit ou abort) Il permet de défaire les mises à jour effectuées par une transaction Journal des images après Journal contenant les débuts de transactions, les valeurs d'enregistrement après mises à jour, les fins de transactions (commit ou abort) Il permet de refaire les mises à jour effectuées par une transaction

Journaux et Sauvegarde Journal des images avant Utilisé pour défaire les mises à jour : Undo 2.Log Page lue Page modifiée 3.Update 1.Read 4.Write Base de données

Journaux et Sauvegarde Journal des images après Utilisé pour refaire les mises à jour : Redo 3.Log Page lue Page modifiée 2.Update 1.Read 4.Write Base de données

Journaux et Sauvegarde Gestion du journal Journal avant et après sont unifiés Écrits dans un tampon en mémoire et vider sur disque en début de commit Structure d'un enregistrement : N transaction (Trid) Type enregistrement {début, update, insert, commit, abort} TupleId [Attribut modifié, Ancienne valeur, Nouvelle valeur]... Problème de taille on tourne sur N fichiers de taille fixe possibilité d'utiliser un fichier haché sur Trid/Tid

Journaux et Sauvegarde Sauvegarde Sauvegarde périodique de la base toutes les heures, jours,... Doit être effectuée en parallèle aux mises à jour Un Point de Reprise (checkpoint) est écrit dans le journal pour le synchroniser par rapport à la sauvegarde permet de situer les transactions effectuées après la sauvegarde Pose d'un point de reprise : écrire les buffers de journalisation (Log) écrire les buffers de pages (DB) écrire un record spécial "checkpoint" dans le journal

Plan Gestion des Transactions Objectifs et bases PLAN Journaux et reprise Scénarios de reprise Modèles étendus de transaction Transactions réparties Moniteurs transactionnels Conclusions

Scénarios de Reprise Les mises à jour peuvent être effectuées directement dans la base (en place) la base est mise à jour immédiatement, ou au moins dès que possible pendant que la transaction est active Les mises à jour peuvent être effectuées en mémoire et installées dans la base à la validation (commit) le journal est écrit avant d'écrire les mises à jour

Scénarios de Reprise Stratégie do-undo Mises à jour en place l'objet est modifié dans la base Utilisation des images avant copie de l'objet avant mise à jour utilisée pour défaire en cas de panne Update Mémoire cache 1. LirePage 2. LogPage 3. WritePage Journal avant Undo Base

Scénarios de Reprise Stratégie do-redo Mises à jour en différentiel l'objet est modifié en page différentielle (non en place/journal) Utilisation des images après copie de l'objet en journal après mise à jour (do) utilisée pour refaire en cas de panne (redo) Update Mémoire cache 1. LirePage 3. LogPage 2. WritePage Journal après Redo Base Ombre Commit

Pages ombres Scénarios de Reprise Table des Pages Ombres Nom Fichier Adresse Table des Pages COMMIT Page Ombre Page Ombre Nouvelle Table des Pages Nouvelles Pages

Scénarios de Reprise La gestion des buffers Bufferisation des journaux on écrit le journal lorsqu'un buffer est plein ou lorsqu'une transaction commet Bufferisation des bases on modifie la page en mémoire le vidage sur disque s'effectue en différé (processus E/S) Synchronisation journaux / base le journal doit toujours être écrit avant modification de la base!

Scénarios de Reprise Commits bloqués AFIN D'EVITER 3 E/S POUR 1: Le système reporte l'enregistrement des journaux au commit Il force plusieurs transactions à commettre ensemble Il fait attendre les transactions au commit afin de bloquer un buffer d'écriture dans le journal RESULTAT La technique des "commits" bloques permet d'améliorer les performances lors des pointes sans faire attendre trop sensiblement les transactions

Scénarios de Reprise Reprise à froid En cas de perte d'une partie de la base, on repart de la dernière sauvegarde Le système retrouve le checkpoint associé Il ré-applique toutes les transactions commises depuis ce point (for each committed Ti : redo (Ti))

Plan Gestion des Transactions Objectifs et bases PLAN Journaux et reprise Scénarios de reprise Modèles étendus de transaction Transactions réparties Moniteurs transactionnels Conclusions

Modèles étendus de transaction Applications longues composées de plusieurs transactions coopérantes Seules les mises-à-jour sont journalisées Si nécessité de défaire une suite de transactions : contexte ad-hoc dans une table temporaire nécessité d'exécuter des compensations

Modèles étendus de transaction Points de sauvegarde Introduction de points de sauvegarde intermédiaires (savepoint, commitpoint) Begin_Trans update update savepoint update update Commit unité d'oeuvre unité d'oeuvre Non perte du contexte

Modèles étendus de transaction Transactions Imbriquées OBJECTIFS Obtenir un mécanisme de reprise multi-niveaux Permettre de reprendre des parties logiques de transactions Faciliter l'exécution parallèle de sous-transactions SCHEMA Reprises et abandons partiels Possibilité d'ordonner ou non les sous-transactions Begin(t'1) Commit(t'1) Begin(T) Commit(T) Begin(t1) Commit(t1) Commet t1 Begin(t2) Begin(t21) Commit(t21) Abort(t2) Annule t2 et t21

Modèles étendus de transaction Sagas Groupe de transactions avec transactions compensatrices En cas de panne du groupe, on exécute les compensations T1 T2 T3... Tn T1 T2 CT2 CT1

Modèles étendus de transaction Activités : Propriétés souhaitées contexte persistant rollforward, rollback avec compensations flot de contrôle dépendant des succès et échecs différencier les échecs systèmes des échecs de programmes monitoring d'activités: état d'une activité, arrêt,...

Modèles étendus de transaction Langage de contrôle d'activités Exemple: réservation de vacances T1 : réservation avion alternative : location voiture T2 : réservation hôtel T3 : location voiture Activité Ensemble d'exécution de transactions avec alternative ou compensation Langage de contrôle d'activités Possibilité de transactions vitales (ex: réservation hôtel) Langage du type : If abort, If commit, Run alternative, Run compensation,

Plan Gestion des Transactions Objectifs et bases PLAN Journaux et reprise Scénarios de reprise Modèles étendus de transaction Transactions réparties Moniteurs transactionnels Conclusions

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

Transactions Réparties Commit en 2 phases Principe 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 Coordinateur : Le composant système d'un site qui applique le protocole Participant : Le composant système d'un autre site qui participe dans l'exécution de la transaction

Transactions Réparties Protocole C/S 1. PREPARER Le coordinateur demande aux autres sites s ils sont prêts à commettre leurs mises à jour. 2a. SUCCES : COMMETTRE Tous les participants effectuent leur validation sur ordre du client. 2b. ECHEC : ABORT Si un participant n est pas prêt, le coordinateur demande à tout les autres sites de défaire la transaction. REMARQUE 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 Transactions Réparties SITE COORDINATEUR SITE PARTICIPANT 1 SITE PARTICIPANT 2 PREPARE PREPARE OK COMMIT ACK OK COMMIT ACK

Cas défavorable Transactions Réparties SITE COORDINATEUR SITE PARTICIPANT 1 SITE PARTICIPANT 2 PREPARE PREPARE OK ABORT KO ABORT ACK ACK

Cas défavorable ( ) SITE PARTICIPANT 1 Transactions Réparties SITE COORDINATEUR SITE PARTICIPANT 2 PREPARE PREPARE OK COMMIT ACK OK COMMIT STATUS COMMIT ACK

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

Transitions d'états Transactions Réparties Initial CCommit/Prepare VoteKO/GAbort Abort Wait VoteOK/GCommit Commit Initial Prepare/VoteOK COORDINATEUR GAbort/Ack Abort Ready GCommit/Ack Commit PARTICIPANT

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

Transactions Réparties Commit en 3 phases Inconvénient du commit à 2 phases 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 Prepare, Prepare to Commit, Global-Commit, Global-Abort. Initial CCommit/Prepare Wait VoteKO/GAbort VoteOK/PréCommit Abort PréCommit PréOK/GCommit Commit Initial Prepare/VoteOK Ready GAbort/Ack PréCommit/PréOK Abort PréCommit Commit GCommit/Ack

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

Plan Gestion des Transactions Objectifs et bases PLAN Journaux et reprise Scénarios de reprise Modèles étendus de transaction Transactions réparties Moniteurs transactionnels Conclusions

Moniteurs transactionnels Support de transactions ACID Accès continu aux données Reprise rapide du système en cas de panne Sécurité d'accès Performances optimisées Partage de connexions Réutilisation de transactions Partage de charge Distribution de transactions Support de bases hétérogènes Respect des normes et standards

Modèle Moniteurs transactionnels Modèle DTP de l X/OPEN Programme d application AP Gestionnaire de transactions TM Gestionnaire de communication CRM Gestionnaire de ressources RM Interfaces standards TX = interface du TM XA = interface du RM intégration de TP Types de RM gestionnaire de fichiers SGBD périphérique AP TX TM CRM TM RM XA

Interface applicative TX tx_open Moniteurs transactionnels ordonne au TM d initialiser la communication avec tous les RM dont les librairies d accès ont été liées à l application. tx_begin ordonne au TM de demander aux RM de débuter une transaction. tx_commit ou tx_rollback ordonne au TM de coordonner soit la validation soit l abandon de la transaction sur tous les RM impliqués. tx_set_transaction_timeout positionne un timeout sur les transactions tx_info permet d obtenir des informations sur le statut de la transaction.

Interface ressource XA xa_open Moniteurs transactionnels ouvre un contexte pour l application. xa_start débute une transaction. xa_end indique au RM qu il n y aura plus de requêtes pour le compte de la transaction courante. xa_prepare lance l étape de préparation du commit à deux phases. xa_commit valide la transaction. xa_rollback abandonne la transaction.

Principaux moniteurs Encina de Transarc Moniteurs transactionnels issu de CMU (1992), racheté par IBM construit sur DCE (OSF) pour la portabilité et la sécurité transactions imbriquées conformité DTP : Xa, CPI-C, TxRPC Open CICS de IBM construit sur Encina (et DCE) reprise de l existant CICS (API et outils) conformité DTP : Xa, CPI-C

Principaux moniteurs ( ) Tuxedo de USL éprouvé (depuis 1984), à la base de DTP supporte l asynchronisme, les priorités et le routage dépendant des données conformité DTP: Xa, Tx, XaTMI, CPI-C, TxRPC Top End de NCR produit stratégique d AT&T respecte le modèle des composants DTP (AP, RM, TM, CRM) haute disponibilité Moniteurs transactionnels conformité DTP: Xa, Xa+, Xap-Tp, Tx Autres : UTM de Siemens, Unikix

Le marché Moniteurs transactionnels 900 800 millions $ 700 600 500 400 300 200 100 Tuxedo Encina CICS UTM TOP END Autres 0 1994 1995 1996 1997 Gartner Group

MTS de Microsoft Microsoft Transaction Server Intégré à DCOM Partage de grappes de NT (cluster) Les disques sont supposés partagés Allocation des ressources en pool aux requêtes : pool de connexion aux ressources (SQL Server) pool de transactions (support) pool de machines Ne suit pas les standards! Moniteurs transactionnels

Plan Gestion des Transactions Objectifs et bases PLAN Journaux et reprise Scénarios de reprise Modèles étendus de transaction Transactions réparties Moniteurs transactionnels Conclusions

Conclusions Des techniques complexes Un problème bien maîtrisé dans les SGBDR La concurrence complique la gestion de transactions Les transactions longues restent problématiques Enjeu essentiel pour le commerce électronique validation fiable reprise et copies partage de connections partage de charge