1  G. Gardarin GESTION DE TRANSACTIONS l 1. Objectifs et bases l 2. Journaux et reprise l 3. Scénarios de reprise l 4. Modèles étendus l 5. Cas des systèmes.

Présentation au sujet: "1  G. Gardarin GESTION DE TRANSACTIONS l 1. Objectifs et bases l 2. Journaux et reprise l 3. Scénarios de reprise l 4. Modèles étendus l 5. Cas des systèmes."— Transcription de la présentation:

1 1  G. Gardarin GESTION DE TRANSACTIONS l 1. Objectifs et bases l 2. Journaux et reprise l 3. Scénarios de reprise l 4. Modèles étendus l 5. Cas des systèmes répartis

2 2  G. Gardarin 1. Le transactionnel (OLTP) l 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 l 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

3 3  G. Gardarin La base TPC-A/ TPC-B Comptes Caissiers Agences Historique 1 100 100000 Taille pour 10 terminaux, avec règle d'échelle ( scaling rule)

4 4  G. Gardarin La transaction Débit - Crédit l Begin-Transaction  Update Account Set Balance = Balance + Delta// Montant 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 ; l End-Transaction. l 90 % doivent avoir un temps de réponse < 2 secondes l Chaque terminal génère une transaction toute les 10s  Performance = Nb transactions commises /Temps exécution moyen  Temps exécution moyen =Ellapse time

5 5  G. Gardarin Cohabitation avec le décisionnel l Les transactions doivent souvent cohabiter avec des requêtes décisionnelles, traitant un grand nombre de tuples en lecture l 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 ;

6 6  G. Gardarin Les menaces l Problèmes de la gestion des accès concurrents  Pertes d'opérations.  Introduction d'incohérences.  Verrous mortels (deadlock). l Panne de transaction  Erreur en cours d'exécution du programme applicatif.  Nécessité de défaire les mises à jour effectuées. l Panne système  Reprise avec perte de la mémoire centrale.  Toutes les transactions en cours doivent être défaites. l Panne disque  Perte de données de la base, d'où sauvegardes!

7 7  G. Gardarin Propriétés des transactions l Transaction  Séquence d'opérations liées comportant des mises à jour ponctuelles d'une base de données devant vérifier les propriétés ACID l Atomicité  Unité de cohérence : toutes les mises à jour doivent être effectuées ou aucune. l Cohérence  La transaction doit faire passer la base de donnée d'un état cohérent à un autre. l Isolation  Les résultats d'une transaction ne sont visibles aux autres transactions qu'une fois la transaction validée. l Durabilité  Les modifications d'une transaction validée ne seront jamais perdue

8 8  G. Gardarin Opérations Commit et Abort l INTRODUCTION D'ACTIONS ATOMIQUES  Commit (fin avec succès) et Abort (fin avec échec).  Ces actions s'effectuent en fin de transaction. l COMMIT  Validation de la transaction.  Rend effectives toutes les mises à jour de la transaction. l ABORT  Annulation de la transaction.  Défait toutes les mises à jour de la transaction.

9 9  G. Gardarin - 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 Schéma d'une transaction simple l Fin avec succès ou échec l Begin_Transaction  update .....  Commit ou Abort

10 10  G. Gardarin Effet logique Mémoire de la transaction Update Commit Abort Bases de données Poubelle

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

12 12  G. Gardarin 2. Journaux et sauvegardes l 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 l 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

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

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

15 15  G. Gardarin Gestion du journal l Journal avant et après sont unifiés. l Écrits dans un tampon en mémoire et vidés sur disque en début de l'opération commit l Structure d'un enregistrement :  N° transaction (Trid)  Type enregistrement {début, update, insert, commit, abort}  TupleId  [Attribut modifié, Ancienne valeur, Nouvelle valeur]... l Problème de taille  On travaille avec N fichiers de taille fixe.  Possibilité d'utiliser un fichier haché sur Trid/Tid.

16 16  G. Gardarin Sauvegarde l Sauvegarde périodique de la base  toutes les heures, jours,...  Doit être effectuée en parallèle aux mises à jour l 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 l Pose d'un point de reprise :  écrire les tampons de journalisation (Log)  écrire les tampons de pages (DB)  écrire un enregistrement spécial "checkpoint" dans le journal.

17 17  G. Gardarin 3. Scénarios de Reprise l Les mises à jour peuvent être effectuées directement dans la base (en place)  la base est mise à jour immédiatement, ou "dès que possible" pendant que la transaction est active. l Les mises à jour peuvent être effectuées en mémoire et installées dans la base à la validation (commit)  le journal est écrit avant l'écriture des mises à jour.

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

19 19  G. Gardarin Ombre Mémoire cache Base Update 1. LirePage 3. LogPage 2. WritePage Redo Journal après Commit Stratégie do-redo l Mises à jour en différentiel  l'objet est modifié en page différentielle (non en place/journal) l 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)

20 20  G. Gardarin Pages ombres Nom Fichier Adresse Table des Pages Table des Pages Ombres Page Ombre Nouvelles Pages Nouvelle Table des Pages COMMIT Page Ombre

21 21  G. Gardarin La gestion des tampons (buffers) l Bufférisation des journaux  on écrit le journal lorsqu'un tampon est plein  ou lorsqu'une transaction commet.. l Bufférisation des bases  on modifie la page en mémoire  le vidage sur disque s'effectue en différé (processus E/S) l Synchronisation journaux / base  le journal doit toujours être écrit avant modification de la base !

22 22  G. Gardarin Commits bloqués l Afin d'éviter 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 tampon d'écriture dans le journal. l Résultat  La technique des "commits" bloqués permet d'améliorer les performances lors des pointes sans faire attendre trop sensiblement les transactions.

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

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

25 25  G. Gardarin Points de Sauvegardes l Introduction de points de sauvegarde intermédiaires  (savepoint, commitpoint) l Begin_Trans  update  savepoint  update l Commit unité d'oeuvre Non perte du contexte

26 26  G. Gardarin Begin(T) Begin(t1) Commit(t1) Begin(t2) Abort(t2) Begin(t21) Commit(t21) Commit(T) Annule t2 et t21 Commet t1 Begin(t'1) Commit(t'1) Transactions Imbriquées l 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 l SCHEMA  Reprises et abandons partiels  Possibilité d'ordonner ou non les sous-transactions

27 27  G. Gardarin Sagas... T1T1 T2T2 T3T3 TnTn T1T1 T2T2 CT 2 CT 1 l Groupe de transactions avec transactions compensatrices. l En cas de panne du groupe, on exécute les compensations.

28 28  G. Gardarin Activités : propriétés souhaitées l Contexte persistant. l rollforward, rollback avec compensations. l Flot de contrôle dépendant des succès et échecs.  différencier les échecs systèmes des échecs de programmes l Monitoring d'activités:  état d'une activité, arrêt,...

29 29  G. Gardarin Langage de Contrôle d'Activités l Exemple: réservation de vacances  T1 : réservation avion alternative : location voiture  T2 : réservation hôtel  T3 : location voiture l Activité  Ensemble d'exécution de transactions avec alternative ou compensation l Langage de contrôle d'activités  Possibilité de transactions vitales (ex: réservation hôtel)  Langage du type : l If abort, If commit, Run alternative, Run compensation, …

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

31 31  G. Gardarin Commit en 2 Phases l Principe  Division de l'opération COMMIT en deux phases :  Phase 1 l Préparation de l'écriture des résultats des mises à jour dans la BD. l Centralisation du contrôle.  Phase 2 l Écriture des résultats dans la BD. l Coordinateur de l'opération :  Le composant système d'un site qui applique le protocole l Participant :  Le composant système d'un autre site qui participe à l'exécution de la transaction

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

33 33  G. Gardarin Cas favorable SITE COORDINATEUR SITE PARTICIPANT 2 SITE PARTICIPANT 1 PREPARE OK COMMIT ACK

34 34  G. Gardarin Cas défavorable (1) PREPARE OK ACK KO ABORT ACK SITE COORDINATEUR SITE PARTICIPANT 2 SITE PARTICIPANT 1

35 35  G. Gardarin Cas défavorable (2) PREPARE OK ACK OK COMMIT STATUS COMMIT ACK SITE COORDINATEUR SITE PARTICIPANT 2 SITE PARTICIPANT 1

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

37 37  G. Gardarin Initia l Wait AbortCommit CCommit/Prepare VoteKO/GAbortVoteOK/GCommit Initial Ready AbortCommit Prepare/VoteOK GAbort/Ack GCommit/Ack COORDINATEUR PARTICIPANT Transitions d'états

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

39 39  G. Gardarin Initial Wait Abort PréCommit Commit CCommit/Prepare VoteKO/GAbort VoteOK/PréCommit PréOK/G Com mit Initial Ready Abort PréCommit Commit Prepare/VoteOK GAbort/Ack PréCommit/PréOK GCommit/Ack Commit en 3 Phases l 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 l Messages du commit à 3 phases  Prepare,  Prepare to Commit,  Global-Commit,  Global-Abort.

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

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

42 42  G. Gardarin TM CRM AP RM TX XA Moniteur transactionnel : Modèle l Modèle DTP de l'X/OPEN  Programme d'application AP  Gestionnaire de transactions TM  Gestionnaire de communication CRM  Gestionnaire de ressources RM l Interfaces standards  TX = interface du TM  XA = interface du RM  intégration de TP l Types de RM  gestionnaire de fichiers  SGBD  périphérique

43 43  G. Gardarin Interface applicative TX l tx_open  ordonne au TM d'initialiser la communication avec tous les RM dont les librairies d'accès ont été liées à l'application. l tx_begin  ordonne au TM de demander aux RM de débuter une transaction. l 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. l tx_set_transaction_timeout  positionne un “ timeout ” sur les transactions l tx_info  permet d'obtenir des informations sur le statut de la transaction.

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

45 45  G. Gardarin Principaux moniteurs (1) l Encina de Transarc  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 l Open CICS de IBM  Construit sur Encina (et DCE)  Reprise de l'existant CICS (API et outils)  Conformité DTP : Xa, CPI-C

46 46  G. Gardarin Principaux moniteurs (2) l 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 l Top End de NCR  Produit stratégique d'AT&T  Respecte le modèle des composants DTP (AP, RM, TM, CRM)  Haute disponibilité  Conformité DTP: Xa, Xa+, Xap-Tp, Tx l Autres : UTM de Siemens, Unikix

47 47  G. Gardarin Le marché Gartner Group

48 48  G. Gardarin MTS de Microsoft l Microsoft Transaction Server l Intégré à DCOM l Partage de grappes de NT (cluster) l Les disques sont supposés partagés. l Allocation des ressources en pool aux requêtes :  pool de connexion aux ressources (SQL Server),  pool de transactions (support),  pool de machines. l Ne respecte pas les standards !

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