Gestion des transactions et des accs concurrents Principaux

Gestion des transactions et des accès concurrents

Principaux modules d’un SGBD (Rappel) Pages Web Application Commandes SQL Exécuteur de plan Concurrence Gestion de la concurrence Evaluateur d'opérateur Interface SQL Parser Moteur d'évaluation Optimiseur des requêtes Gestionnaire de fichiers Gestionnaire de transactions Gestionnaire de buffer Gestionnaire de verrous Gestionnaire de panne Gestionnaire de disque SGBD BD Fichiers index de Fichiers données Catalogue du système 2

Contexte ■ Plusieurs programmes/utilisateurs manipulent la BD en même temps. ■ Des pannes peuvent surgir ■ Ce qu’on veut faire : 1. Cohabiter les différents utilisateurs: q La base de données doit paraître cohérente pour chaque utilisateur, q les contraintes doivent être vérifiées ( débits = crédits). 2. Garantir un comportement cohérent en cas de pannes 3

1. Critères de cohérence d’une BD ■ Intégrité sémantique q respect des contraintes d’intégrité ■ Contrôle de concurrence (Objet de ce chapitre) q concurrence sans interférence indésirable ■ Fiabilité (sûreté de fonctionnement) q pannes matérielles ou logicielles (chapitre suivant) ■ Sécurité (confidentialité) q q Vues Privilèges (identification + authentification) 4

Concurrence et reprise ■ Ce chapitre concerne le contrôle de la concurrence (CC). ■ La réparation des pannes (recovery) fera l’objet du chapitre suivant. ■ Remarque: ces 2 fonctionnalités sont très liées bien qu’on va les étudier séparément. ■ La notion de transaction est cruciale pour la compréhension de ces 2 fonctionnalités. ■ On se place dans le cadre d’un SGBD centralisé. – Les techniques étudiées peuvent être adaptées dans le cas d’un SGBD distribué. 5

Avantages et inconvénients de la concurrence ■ Avantages – Utilisation efficace des ressources de la machine (disques et CPU) – Réduction du temps moyen de réponses des applications BD ■ Inconvénients – Risque d’interférence non désirable entre plusieurs programmes BD – Complexe à réaliser 6

1. 1 Notion de transaction ■ Définition – Une ou plusieurs opérations d’un utilisateur ou d’une application, qui accède(nt) ou modifie(nt) les données de la base, transformant la BD d'un état cohérent en un autre état cohérent Les mises à jour sont problématiques ■ Ainsi, une transaction = unité de programme exécutée sur SGBD comme une seule entité : – soit toutes les instructions sont exécutées ensemble, – soit aucune ne l'est. – Début Transaction q Accès à la BD (lectures, écritures) q Calculs en mémoire centrale – Fin Transaction : Validation (COMMIT) ou Annulation (ROLLBACK) 7

1. 1 Notion de transaction ■ On adopte alors les règles suivantes : 1. Quand une transaction est validée (par commit), toutes les opérations sont validées ensemble, et on ne peut plus en annuler aucune. En d’autres termes les mises à jour deviennent définitives. 2. Quand une transaction est annulée par rollback ou par une panne, on annule toutes les opérations depuis le dernier commit ou rollback, ou depuis le premier ordre SQL s’il n’y a ni commit ni rollback. ■ Effet logique Mémoire de la transaction Update Commit Bases de données Rollback Poubelle 8

Exemple d’une transaction: Virement bancaire Cours bda 6 -seconf page 62 Virement = 2 opérations atomiques (Retrait + dépôt) Que se passe-t-il si le Dépôt échoue ? Compte courant = 500 / CODEVI = 110 Recommencez ! 9

Propriétés ACID d’une transaction ■ Pour assurer la cohérence sémantique de la BD, le SGBD doit garantir 4 propriétés des transactions: – Atomicité : Tout ou rien q Une transaction effectue toutes ses actions ou aucune. q En cas d’annulation, les modifications engagées doivent être défaites. – Cohérence : Intégrité des données q Passage d’un état cohérent de la base à un autre état cohérent de la BD. – Isolation : Pas d'interférence entre transactions q Les résultats d’une transaction ne sont visibles par les autres transactions qu’après sa validation (chaque transaction doit s'exécuter comme si aucune autre ne s'exécutait en même temps). – Durabilité : Journalisation des mises à jour q Les modifications effectuées sont garanties même en cas de panne. 10

Exemple de transaction ■ Soit la transaction qui transfère 1000 dinars d’un compte A vers un compte B 1. 2. 3. 4. 5. 6. Lire (A) A: =A - 1000 Ecrire (A) Lire (B) B: = B + 1000 Ecrire (B) ■ Le critère de cohérence de la BD est que la somme A+B reste inchangé après la fin de la transaction. ■ Si la transaction échoue après l’étape 3 alors le SGBD doit s’assurer que les modifications de A ne sont pas persistantes (Atomicité). ■ Une fois, la transaction est finie sans problème, l’utilisateur n’a plus à douter de la réussite de l’opération de transfert même en cas de crash système (Durabilité). ■ Si entre les opérations 3 et 6, une autre transaction lit la BD, elle va avoir un état incohérent (A+B est inférieur à ce qu’il doit être !). C’est le problème d’Isolation. 11

Gestionnaire de transactions (Moniteur des transactions ou moniteur TP) ■ Système qui assure une gestion des transactions. – Il doit apporter la garantie que, lors de l’exécution d’une ou d’un ensemble de transactions, toutes les propriétés d'une transaction sont satisfaites, même en cas de défaillance du système. ■ Opérations des transactions – Lecture – Écriture – Validation (commit en anglais). Elle consiste à rendre les mises à jour permanentes. – Annulation (rollback). Elle annule les mises à jour effectuées. 12

Principales causes d’annulation ■ Annulation par le SGBD (exemple : détection d'un inter blocage) ■ Erreur du SGBD ■ Erreur du système d'exploitation ■ Erreur locale à une transaction ■ Panne de matériel ■ etc. 13

2. Contrôle de la concurrence ■ C’est le processus qui permet d’empêcher que des interférences d’opérations simultanées de plusieurs transactions n’engendrent pas une BD incohérente. ■ Les transactions de lecture seulement ne nécessitent pas un tel processus. ■ Par contre, des transactions qui font des écritures dans la BD, peuvent causer des interférences indésirables pouvant générer une BD incohérente. ■ le CC devient une nécessité pour le SGBD. 14

2. 1 Interférences (ou entrelacement ) entre transactions ■ Par définition toute transaction T est correcte à partir d'un état cohérent son exécution amène à un autre état cohérent. ■ Pour des raisons d'efficacité, il est nécessaire d'autoriser l'exécution concurrente des transactions. ■ Tout le problème réside alors dans le fait qu'il faut gérer ces exécutions concurrentes pour qu'elles ne conduisent pas à une base incohérente. C'est l'entrelacement non contrôlé (ou interférences) des opérations de deux transactions correctes qui peut produire un résultat global incorrect. – Les opérations sont toujours exécutées en séquence. ■ Trois types de problèmes peuvent apparaître: – Perte de maj. (lost update) – Lecture sale (dirty Read) ou dépendance non confirmée (uncommitted dependency) – Lecture non reproductible (non repeatable Read) q Lecture fantôme 15

Perte de maj. (lost update) ■ Une opération de maj. d’une transaction, terminée et confirmée, est écrasée par celle d’une autre transaction. Temps T 1 T 2 Soldex (BD) Begin 100 T 2 Begin Read(soldex) 100 T 3 Read(soldex) Soldex += 100 T 4 Soldex -= 10 Write(soldex) 200 T 5 Write(soldex) commit 90 t 6 commit 90 BD cohérente si soldex = 190 T 2 puis T 1 => 100+100 -10 OU T 1 puis T 2 => 100 -10+100 16

Dépendance non confirmée (uncommitted dependency) ou Lecture sale (Dirty read) ■ Le non respect de l’isolation: une transaction est autorisée à voir les résultats d’une autre transaction active (non encore confirmée). Temps Lecture impropre : lecture d'une donnée "non confirmée" T 3 T 4 Soldex (BD) T 1 Begin 100 T 2 Read(soldex) 100 T 3 Soldex += 100 T 4 Write(soldex) 200 T 5 Begin 200 T 6 Read(soldex) 200 T 7 Rollback 100 T 8 Soldex -= 10 200 T 9 Write(soldex) 190 T 10 commit 190 La valeur cohérente de soldex doit être 90 au lieu de 190 17

Lecture non reproductible (non repeatable Read) ■ Une transaction lit des valeurs de la BD pour les utiliser alors qu'une autre transaction modifie certaines de ces données. < user 1 récupère les produits dont la quantité > 50. < user 1 agit sur les lignes retournées par la requête (y compris 123), < user 2 a changé la quantité de la ligne 123 de 60 à 40. < user 1 répète la demande de recherche dans le cadre de la transaction. < user 1 ne trouve plus ligne 123 Transaction A Transaction B SELECT ligne n° 123 Quantité = 60 SELECT ligne n° 123 Update ligne n° 123 SET Quantité = 40 COMMIT SELECT une autre fois ligne n° 123 n'existe plus COMMIT 18

Lecture fantôme Un autre problème se produit lorsqu’une transaction exécute une requête qui recherche un ensemble de tuples d’une relation satisfaisant un certain prédicat, puis exécute un peu plus tard la même requête pour constater que l’ensemble obtenu contient un tuple supplémentaire ou fantôme inséré entre temps par une autre transaction : lecture fantôme. Transaction A SELECT lignes – ligne n° 999 inexistante Transaction B Lire ligne n° 123 INSERT ligne n° 999 COMMIT SELECT une autre fois – ligne n° 999 existe COMMIT 19

Problème des fantômes ■ Exemple Temps Transaction T 1 t 1 Début. Transaction t 2 Effectuer le total des soldes comptes du client 10 t 3 t 4 t 5 t 6 t 7 t 8 Transaction T 2 État de la BD Environnement Le client possède un compte de 100 D et un autre de 200 D Les deux comptes sont verrouillés par T 1 Début. Transaction Insérer un nouveau Le nouveau compte est compte pour le client verrouillé par T 2 : PAS 10 avec un dépôt initial DE CONFLIT… de 100 000 D Confirmer. Transaction Créer un nouveau compte en Suisse et y déposer le total Supprimer tous les comptes du client 10 Confirmer. Transaction Nouveau compte créé en Suisse contient 300 D Supprime aussi nouveau compte… le 20

2. 2 Théorie de la sérialisation ■ L'objectif d'un protocole de CC est d’éviter les 3 problèmes précédents ■ Solution triviale: exécuter les transactions l’une après l’autre – – Aucune concurrence une transaction longue bloque toutes les autres Temps de réponse inacceptable Simultanéité possible entre transactions non interférentes ■ Autre Sérialisation – identifier les exécutions qui garantissent la cohérence de la BD ■ On parle d'ordonnancements sérialisables 21

Définitions ■ On ne considère que les opérations Read et Write sur la BD ■ Ordonnancement de plusieurs transactions T 1, T 2, . . . , Tn – Ensemble de Read et de Write de T 1, T 2, . . . , Tn ■ Ordonnancement sériel (ou séquentiel) – Les transactions sont exécutées l’une à la suite de l’autre sans aucune interférence avec d’autres transactions (pas de parallélisme). ■ Ordonnancement non sériel – Les opérations R et W des différentes transactions s’interfèrent mais leur ordre relatif (intra transaction) est respecté. – L’ordonnancement non sériel est correct s’il produit les mêmes résultats et a les mêmes effets sur la BD qu’un ordonnancement série des mêmes transactions et cela quelque soit l’état initial de la BD. 22

Ordre des opérations R et W ■ L’ordonnancement séquentiel empêche l’apparition des 3 problèmes de la concurrence Chaque exécution séquentielle est considérée correcte ■ Objectif de la sérialisabilité – Trouver un ordonnancement non sériel qui produit le même résultat qu’un ordonnancement sériel – Un tel ordonnancement est dit sérialisable ■ L’ordre des R et W est important dans la sérialisabilité – T 1 lit et T 2 lit => l’ordre n’est pas important (pas de conflit) – Si T 1 et T 2 lisent ou écrivent des items non communs => l’ordre n’est pas important (pas de conflit) – Si l’une écrit un item qui est lu ou écrit par la suite par une autre transaction => l’ordre d’exécution est fondamental ! – Définition : Un ordonnancement est correct s’il est sérialisable, c-à-d équivalent à un ordonnancement série formé des mêmes transactions. 23

Ordonnancement séquentiel Temps Transaction T 1 t 1 Début. Transaction t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 Lire(Solde. Compte, s) s = s + 700 Écrire(s, Solde. Compte) Confirmer. Transaction T 2 État de la BD Solde. Compte 1000 Solde. Compte 1700 Début. Transaction Lire(Solde. Compte, s) s = s + 200 Écrire(s, Solde. Compte) 1900 Confirmer. Transaction = = = 24

Ordonnancement (non séquentiel) sérialisable Temps Transaction T 1 t 1 Début. Transaction t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 t 11 t 12 t 13 Lire(Solde. Compte 1, s 1) s 1: = s 1 -100 Transaction T 2 État de la BD Solde. Compte 1 $300 Solde. Compte 2 $500 Environnement = = Début. Transaction Lire(Solde. Compte 1, s 1) Lire(Solde. Compte 2, s 2) total = s 1 + s 2 Afficher(s 1, s 2, total) Affiche $800 $300, $500, Confirmer. Transaction Écrire(s 1, Solde. Compte 1) Lire(Solde. Compte 2, s 2) s 2: = s 2+100 Écrire(s 2, Solde. Compte 1 $200 Solde. Compte 2 $500 = Solde. Compte 1 = = 25

Graphe de précédence ■ Définition: – Deux opérations O 1 et O 2 sont en conflit si : q elles sont produites par de transactions différentes Ti et Tj q réagissent sur la même variable q O 1=R et O 2 =W et O 1 avant O 2 ou inversement ■ On construit un graphe G : – les nœuds sont les transactions de l’ordonnancement à tester – les arcs sont définies comme suit: q Ti Tj : si Ti comporte une opération en conflit avec une opération de Tj ■ Proposition – Si G contient un cycle alors l’ordonnancement n’est pas sérialisable (l’inverse n’est pas vraie) – Sinon G (un tri topologique) donne les ordonnancements sériels équivalents 26

Graphe de précédence { T 1 : Lire A ; T 2 : Ecrire A ; T 2 : Lire B ; T 2 : Ecrire B ; T 3 : Lire A ; T 1 : Ecrire B } Exemple de graphe de précédence < L’ Ordonnancement n’est pas sérialisable puisque le graphe de précédence présente un circuit. 27

Ordonnancement sérialisable 28

Ordonnancement non sérialisable Temps Transaction T 1 t 1 Début. Transaction t 2 t 3 t 4 Transaction T 2 Lire(Solde. Compte 1, s 1) s 1: = s 1 -100 Écrire(s 1, Solde. Compte 1) Solde. Compte 1 $200 Solde. Compte 2 $500 t 5 t 6 t 7 t 8 t 9 Début. Transaction Lire(Solde. Compte 1, s 1) Lire(Solde. Compte 2, s 2) total = s 1 + s 2 Afficher(s 1, s 2, total) t 10 t 11 t 12 Confirmer. Transaction Lire(Solde. Compte 2, s 2) s 2: = s 2+100 État de la BD Solde. Compte 1 $300 Solde. Compte 2 $500 Environnement = = Affiche $700 Oups! $200, $500, 29

Notation ■ Notation – – ri[x] : la transaction Ti lit la valeur de x wi[x] : la transaction Ti écrit la valeur de x Ci : la transaction Ti valide (Commit) Ri : la transaction Ti abandonne (Rollback) ■ Exemple de transactions – – T 1 : r 1[x] w 1[x] C 1 (crédit) T 2 : r 2[x] w 2[x] r 2[y] w 2[y] C 2 (transfert) T 3 : r 3[x] R 3 (transfert impossible) T 4 : r 4[x] r 4[y] w 4[x] R 4 w 4[y] C 4 Incorrect ! ■ Exemple d’ordonnancements – T 1 : r 1 [x] w 1 [y] w 1 [x] C 1 T 2 : w 2 [x] r 2 [y] w 2 [y] C 2 – O 1 : r 1[x] w 2[x] w 1[y] r 2[y] w 1[x] w 2[y] C 1 C 2 q Conflits : r 1[x]-w 2[x] ; w 2[x]- w 1[x] ; w 1[y]-r 2[y] ; w 1[y]- w 2[y] – O 2 : r 1[x] w 1[y] w 2[x] w 1[x] C 1 r 2[y] w 2[y] C 2 q Conflits : r 1[x]-w 2[x] ; w 2[x]- w 1[x] ; w 1[y]-r 2[y] ; w 1[y]- w 2[y] 30

Notation Exemple 31

Exercice 1: Ordonnancements sérialisables ? 32

Exercice 3: Ordonnancements sérialisables ? 33

Ordonnancement avec cycle mais sérialisable ! Temps t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 Transaction T 1 Début. Transaction Lire(A, a) a: = a 2 Transaction T 2 État de la BD A=1 Début. Transaction Lire(A, a) Écrire(a, A) A=1 a: = a + 10 Écrire(a, A) A = 11 Confirmer. Transaction 34

2. 3 Le verrouillage ■ Technique dont on sait qu’elle garantit la sérialisabilité ■ 2 grandes familles de techniques – Pessimistes q empêchent l'apparition des conflits q préviennent des conflits qui ne surviennent en général pas – Optimistes q On suppose que les conflits sont rares. q On laisse les transactions s'exécuter sans contrôle et on teste les conflits à la confirmation et annulent leurs effets. 35

Le verrouillage ■ Granularité : – – – Base Relation Tuple Attribut Page E/S disque ■ Granule fin (attributs, tuples) q parallélisme élevé q coût en opération de verrouillage et en place occupée élevé ■ Granule épais (relations, base) q faible parallélisme q surcoût négligeable ■ La page d'E/S disque est le granule de verrouillage adopte par de nombreux systèmes 36

Principe du verrouillage ■ Quand une transaction accède à un item de la BD, un verrou peut empêcher les accès à cet item aux autres transactions. Approche la plus utilisée pour assurer la sérialisabilité. ■ Plusieurs variantes de verrouillage ayant en commun l’utilisation de 2 types de verrous (partagé et exclusif) avant l’utilisation de tout item de la BD. ■ Modes de verrouillage – Verrouillage exclusif (X, exclusive lock) – Verrouillage partagé (P, share lock (S)) 37

Verrouillage exclusif ■ Une transaction à la fois (En écriture et en lecture) ■ toute opération d'une transaction T sur une donnée A ne peut se faire que si T obtient un verrou sur A ■ si A est déjà verrouillé par T' quand T le demande, alors T est mis en attente La base L (A) A = 100 L (A) R 1 (A) A : = A +100 W 1 (A) A = 200 U (A) R 2 (A) A = 400 A : = A +200 38

Verrouillage partagé ■ les lectures ont les verrous partagés – T et T' peuvent lire A simultanément ■ les écritures doivent obtenir les verrous exclusifs – si A est déjà verrouillé par T', alors T est mis en attente ■ Avantage: – meilleures performances, – mais influence considérablement les performances d’une BD soumises à un haut régime transactionnel. ■ C'est la méthode la plus utilisée Lr (A) A = 100 R 1 (A) Lr (A) R 2 (A) A : = A +100 A : = A +200 Lw (A) La base 39

Insuffisance du verrouillage ■ Le verrouillage seul ne garantit pas la sérialisabilité – T 7 ajoute 100 à X et retranche 100 à Y, T 8 augmente X et Y de 10% – Avant exécution: X=100 Y=400 – Après exécution: X=220, Y=330 Exécution gauche droite et haut bas T 7: WL(X) T 7: R(X) T 7: W(X) T 7: UL(X) T 8: WL(X) T 8: R(X) T 8: W(X) T 8: UL(X) T 8: WL(Y) T 8: R(Y) T 8: W(Y) T 8: UL(Y) T 8: commit T 7: WL(Y) T 7: R(Y) T 7: W(Y) T 7: UL(Y) T 7: commit T 7 puis T 8: X=220, Y=340 T 8 puis T 7: X=210, Y=340 40

Verrouillage à 2 phases (V 2 P) ■ Le verrouillage des données d'une BD doit être appliqué avec modération. – Si, d'une part, on tente d'augmenter le rendement du traitement simultané des transactions en déverrouillant les données dès que possible, la base peut se retrouver en état inconsistant. – Si, d'autre part, on ne déverrouille pas un article avant d'en verrouiller un autre, on crée des interblocages. Solution : imposer aux transactions de respecter un ensemble de règles appelées protocole de verrouillage qui organise le verrouillage et le déverrouillage des données concernées par les transactions. ■ Le protocole de verrouillage le plus important est le protocole à deux-phases. Si toutes les transactions utilisent ce protocole, alors tous les schémas parallèles qu'on peut former seront sérialisables. 41

Verrouillage à 2 phases (V 2 P): two phase locking ■ Technique de contrôle des accès concurrents consistant à verrouiller les objets au fur et à mesure des accès par une transaction et à relâcher les verrous seulement après obtention de tous les verrous qui lui sont nécessaires. ■ Une transaction émette ses demandes de verrouillage et de déverrouillage en deux phases : q Phase d’acquisition de verrous (growing phase) q Phase de libération de verrous (shrinking phase) ■ Le protocole V 2 P garantit la sérialisabilité 1 er unlock Nbre de verrous Acquisition de verrous Libération de verrous 42

Verrouillage à 2 phases (V 2 P) ■ Chaque transaction doit obtenir un verrou partagé P sur un granule avant de le lire, et un verrou exclusif X sur un granule avant d’effectuer une écriture dessus. ■ Si une transaction émet un verrou X sur un granule, aucune transaction ne peut obtenir un verrou (P ou X) sur le même granule. ■ Initialement, une transaction donnée est en phase de verrouillage croissant. Lorsqu'elle libère un verrou, elle entre en phase de décroissance et aucun verrou ne peut plus être imposé. – Les verrous sont demandés au moyen de l’opération Lock et relâchés au moyen de l’opération Unlock. ■ Lors d’une demande de verrouillage, – si l’objet demandé est verrouillé, la transaction demandante est mise en attente jusqu’à libération de l’objet. – ainsi, toute transaction attend la fin des transactions incompatibles, ce qui garantit un graphe de précédence sans circuit. 43

Graphe de précédence de V 2 P ■ On se base sur les opérations Lock et Unlock de l’ordonnancement O (n opérations) pour construire G: – On dessine un arc de Ti Tj si une opération Ax de O est telle que: Ax= unlock(Ti, X) et il existe une opération Ay =lock(Tj, X) avec y>x ■ Proposition: Si G contient un cycle alors O n’est pas sérialisable Sinon il est sérialisable (tri topologique) 44

V 2 P => Pas de perte de maj. Temps T 1 T 2 Soldex (BD) Begin 100 T 2 Begin WL(soldex) 100 T 3 WL(soldex) Read(soldex) 100 T 4 Wait Soldex += 100 T 5 Wait Write(soldex) 200 T 6 Wait UL(soldex) 200 T 7 Read(soldex) 200 T 8 Soldex - = 10 200 T 9 Write(soldex) 190 T 10 Unlock(soldex) 190 T 11 commit 190 Sans verrouillage Temps T 1 T 2 T 3 T 4 T 5 t 6 T 1 Begin Read(soldex) Soldex -= 10 Write(soldex) commit T 2 Begin Read(soldex) Soldex += 100 Write(soldex) commit Soldex (BD) 100 100 200 90 90 45

V 2 P => Pas de dépendance non confirmée Temps T 3 T 4 Soldex T 1 Begin 100 T 2 WL(Soldex) 100 T 3 R(Soldex) 100 T 4 Begin Soldex + = 100 T 5 WL(Soldex) W(Soldex) 200 T 6 WAIT UL(Soldex) 200 T 7 WAIT Roll back 100 T 8 R(Soldex) 100 T 9 Soldex - =10 100 T 10 W(Soldex) 90 T 11 Unlock(Soldex) 90 T 12 Commit 90 Sans verrouillage Temps T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 T 9 T 10 T 3 T 4 Soldex (BD) Begin 100 Read(soldex) 100 Soldex += 100 Write(soldex) 200 Begin 200 Read(soldex) 200 Rollback 100 Soldex -= 10 200 Write(soldex) 190 commit 190 < En pratique: libération des verrous à la fin de la transaction q Cette variante produit aussi des exécutions strictes (empêche les lectures et les écritures sales) 46

V 2 P => Pas de lecture impropre T T 5 1 T 6 Sx Sy Sz Som Begin 100 50 25 ? Sum=0 100 50 25 0 2 Begin 3 WL(Sx) 4 R(Sx) RL(Sx) - - 5 Sx – 10 Wait - - - 0 6 W(Sx) Wait 90 - - 0 7 WL(Sz) Wait 90 - - 0 8 R(Sz) Wait - - - 0 1 9 Sz+10 Wait - - - 0 2 10 W(Sz) Wait 90 50 35 0 11 UL(Sx) UL(Sz) Wait 90 50 35 0 12 Commit Wait 90 50 35 0 13 R(Sx) 90 50 35 14 Som+Sx 90 50 15 RL(Sy) 90 16 R(Sy) 17 Sans verrouillage T T 5 T 6 Sx Sy Sz Som Begin 100 50 25 ? Begin Sum=0 100 50 25 0 3 R(Sx) - - 4 Sx – 10 Som+Sx - - - 100 0 5 W(Sx) R(Sy) 90 - - 100 35 90 6 R(Sz) Som+Sy - - - 150 50 35 90 7 Sz+10 - - 90 50 35 90 Som+Sy 90 50 35 140 8 W(Sz) - - 35 - 18 RL(Sz) 90 50 35 140 9 Commit R(Sz) 90 50 35 150 19 R(Sz) 90 50 35 140 10 Som+Sz - - - 20 Som+Sz 90 50 35 175 185 21 UL(Sx) UL(Sy) UL(Sz) 90 50 35 175 11 commit 22 Commit 90 50 35 17 47

Inconvénients du V 2 P G Le V 2 P garantit la sérialisabilité H Coût élevé lorsque les transactions font référence à de nombreuses données de la base. H Pose 3 principaux problèmes (selon le moment de libération des verrous par les transactions): q Annulation en cascade q Inter blocage (deadlock) q Famine 48

Annulation en cascade (Cascading Rollback) Transactions qui respectent le protocole V 2 P Temps T 7 1 Begin 2 WL(X) 3 R(X) 4 RL(Y) 5 R(Y) 6 W(X) 7 UL(X) Begin 8 … WL(X) 9 … R(X) 10 … X+100 11 … W(X) 12 … UL(X) 13 … … 14 Roll back … Begin Commit RL(X) 15 T 8 T 9 < L’annulation de T 7 entraîne celle de T 8 et de T 9 (à cause de lectures impropres). < Risque de perte de beaucoup de travail. < Solution possible q Retarder la libération des verrous en fin de la transaction. q Selon la nature des verrous, on parle de V 2 P stricte et de V 2 P rigoureux. 16 … 17 Commit 49

Inter blocage (deadlock) ■ Plusieurs transactions sont en attente mutuelle de libération de verrous par d’autres transactions. T 10 T 11 Begin WL(X) Begin R(X) WL(Y) X=X-10 R(Y) W(X) Y=Y+100 WL(Y) WAIT WL(X) WAIT WAIT … … T 10 T 11 Graphe d’attente T 10 attend Y chez T 11 attend X chez T 10 50

Solutions pour l’inter blocage ■ 2 techniques générales utilisées pour gérer les inter blocages – Prévention des inter blocages – Détection et annulation des inter blocages ■ Choix d’une victime (transaction à annuler) dépend : – du temps depuis lequel la transaction s’exécute (la plus vieille, la plus jeune ? la plus récente est moins coûteuse) – du nombre de verrous – du nombre de données modifiées par la transaction – Si trop de temps en attente (limite dépassée) alors annuler la transaction ■ Le choix est fait par le gestionnaire des verrous (lock manager) ■ La victime doit avoir une priorité lors de sa relance (gestion de la famine) ■ Annulations parfois inutiles ■ Problème avec longues transactions 51

Solutions pour l’inter blocage Détection des inter blocages ■ Création d’un graphe d’attente waits-for graph: – Les nœuds représentent les transactions – Il y a un lien de Ti vers Tj si Ti attend que Tj libère un verrou ■ Proposition – inter blocage cycle dans QAQ ■ Périodiquement vérifier s ’il y a un cycle dans le graphe waits-for Prévention des inter blocages ■ Attribuer des priorités sous forme d’estampilles temporelles (timestamps). ■ Supposons que Ti demande un verrou détenu par Tj. Deux cas de figure (Wait. Die et Wound-wait) 52

Estampillage ■ Une autre approche, qui garantit aussi la sérialisation, fait appel à des estampilles de temps, cachetées sur les transactions, de façon à classer l’exécution des transactions dans une planification sérielle équivalente. ■ Le but est d'avoir des ordonnancements sérialisables équivalents à l'ordre chronologique des transactions. ■ Avantages q pas d'interblocage (deadlock) q aucune attente : les transactions qui entrent en conflit sont simplement annulées et redémarrées avec une nouvelle estampille ■ Inconvénient q performances en général moins bonnes que pour le verrouillage 53

Estampillage d'une transaction ■ Toute transaction estampillée avec son temps t de commencement q temps logique ou physique : à partir de l’horloge système au moment du démarrage des transactions ou plus généralement, par incrémentation d’un compteur logique lors de chaque démarrage de transaction. ■ En principe, le plus petit t qui gagne s'il y a un conflit q l'autre transaction est avortée et relancée § peut-être indéfiniment (livelock) 54

Protocole avec estampillage Wait-Die : consiste à annuler les transactions qui demandent des ressources tenues par des transactions plus anciennes. Soit Ti est plus vieille que Tj (E(i) < E(j)) q La transaction la plus récente Tj est alors reprise avec la même estampille ; elle finit ainsi par devenir ancienne et par passer. q les seules attentes possibles étant dans l’ordre où une transaction ancienne attend une transaction récente. // Algorithm WAIT-DIE Procédure Attendre (Ti, Tj) { // Ti réclame un verrou tenu par Tj si ts(Ti) < ts(Tj) alors Ti waits sinon Ti dies ; } Wound-wait : est une technique préventive pour la prévention de blocage. q Une transaction Ti plus ancienne attend une plus récente Tj, la récente (Tj) est blessée (wounded) par Ti, ce qui signifie que Ti ne peut plus attendre. q les seules attentes possibles étant lorsque la transaction Ti est récente que Tj. // Algorithm WOUND-WAIT Procédure Attendre (Ti, Tj) { // Ti réclame un verrou tenu par Tj si ts(Ti) < ts(Tj) alors Tj is wounded sinon Ti waits ; } 55

Estampillage des données ■ En plus des estampilles sur les transactions, il y aussi des estampilles sur les données elles-mêmes. Chaque donnée possède : q une estampille de lecture EL indiquant l’estampille de la dernière transaction ayant lu la donnée et, q une estampille d’écriture EE indiquant l’estampille de la dernière transaction qui a effectué une écriture sur cette donnée. ■ Le contrôleur de concurrence vérifie alors que : 1. les accès en écriture s’effectuent dans l’ordre croissant des estampilles de transactions par rapport aux opérations créant une précédence, donc l’écrivain E et le lecteur L. 2. les accès en lecture s’effectuent dans l’ordre croissant des estampilles de transactions par rapport aux opérations créant une précédence, donc par rapport à l’écrivain E. 56

Protocole avec estampillage Soit une donnée A et Ti une transaction qui utilise A : ■ i est l’estampille de T ■ EL(A) l’estampille de lecture sur A ■ EE(A) l’estampille d’écriture sur A. Procédure de lecture Si EE(A) i alors Exécuter la lecture; EL(A) : = Max (EL(A), i) ; Sinon rejeter ; Finsi Ti est “annulée” et relancée avec une nouvelle estampille (car cela veut dire que Ti essaye de lire une valeur qui a été écrite par une transaction qui est arrivée après elle) 57

Protocole avec estampillage Soit une donnée A et Ti une transaction qui utilise A : ■ i est l’estampille de T ■ EL(A) l’estampille de lecture sur A ■ EE(A) l’estampille d’écriture sur A. Procédure d’écriture Si EL(A) i et EE(A) i alors Exécuter l’écriture ; EE(A) : = i ; Sinon rejeter ; Finsi ■ Si i < EL(A) : dans ce cas, cela veut dire qu’il y a une transaction qui est arrivée après Ti et qui a lu A. Ti est annulée ■ Si i < EE(A) : si on laisse faire cette écriture, alors elle va "écraser" celle faite par une transaction arrivée après Ti. Ti est annulée 58

Algorithme avec la règle d’écriture de Thomas Si EL(A) i alors Si EE(A) i alors Executer l’écriture; EE(A) : = i ; Finsi Sinon rejeter ; finsi ; ■ Exemple : soient les transactions T 1, T 2 et T 3 avec les estampilles respectives e(T 1), e(T 2), e(T 3), avec e(T 1) < e(T 2) < e(T 3) ■ Au temps t 8, l’opération d’écriture par T 2 transgresse la première règle d’écriture, de sorte que T 2 est annulée et redémarrée au temps t 14 ■ Au temps t 14, l’écriture par la transaction T 1 peut être ignorée en toute sécurité en respect de la règle d’écriture obsolète ignorée, puisqu’elle aurait été écrasée par l’opération d’écriture de la transaction T 3 au temps t 12 59

Algorithme avec la règle d’écriture de Thomas Time opération t 1 T 2 T 3 begin transaction t 2 read(soldex) t 3 soldex=soldex+10 t 4 write(soldex) t 5 read(soldey) t 6 soldey=soldey+20 t 7 read(soldey) t 8 write(soldey) t 9 soldey=soldey+30 soldey=soldey+20 t 10 write(soldey) t 11 soldez= 100 t 12 write(soldez) t 13 soldez= 50 soldez=50 t 14 read(soldez) begin transaction t 15 read(soldey) commit read(soldey) t 16 soldey=soldey+20 t 17 write(soldey) t 18 begin tansaction Begin transaction read(soldey) write(soldey) commit 60

3. Contrôle de la concurrence dans SQL Point de vue syntaxe ■ Modèle de transaction basé sur les deux commandes – COMMIT : confirmer la transaction – ROLLBACK: annuler la transaction ■ Demandes explicites de verrouillage – LOCK TABLE, clause FOR UPDATE ■ Pour SQL programmé – Fin normal d’un programme engendre la confirmation même si aucun ordre commit n'a été précisé – Fin anormal d’un programme annule la transaction ■ Pas d'imbrication de transactions 61

4 niveaux d’isolation d’une transaction ■ Lecture impropre ( « READ UNCOMMITTED » ) – autoriser la lecture de tuples écrits par d'autres transactions mais non encore validées ■ Lecture propre ( « READ COMMITTED » ) – lire que les tuples validés (pas de verrou sur une donnée lue). C'est le mode par défaut d'ORACLE. – interdire lecture impropre ■ Lecture reproductible ( « REPEATABLE READ » ) – interdire lecture impropre – garantir relecture sans modifications visibles (exp. V 2 P strict) – permet les fantômes ■ Sérialisable ( « SERIALIZABLE » ) – Le mode le plus strict Niveau Isolation Lec. Impropre Lec. Non Reproductible Lec. Fantôme READ UNCOMMITTED Possible READ COMMITTED Impossible Possible REPEATABLE READ Impossible Possible 62

Transactions dans Oracle ■ Une transaction démarre lorsqu’on exécute une instruction SQL qui modifie la base ou le catalogue (DML et DDL). – Ex : UPDATE, INSERT, CREATE TABLE… ■ Une transaction se termine dans les cas suivants : – – L’utilisateur valide la transaction (COMMIT) L’utilisateur annule la transaction (ROLLBACK sans SAVEPOINT) L’utilisateur se déconnecte (la transaction est validée) Le processus se termine anormalement (la transaction est défaite) ■ Amélioration des performances dans Oracle : – Niveaux d’isolation – Contrôle de concurrence multiversion ■ Verrouillage 63

Commandes transactionnelles ■ COMMIT – Termine la transaction courante et écrit les modifications dans la base. – Efface les points de sauvegarde (SAVEPOINT) de la transaction et relâche les verrous. ■ ROLLBACK – Défait les opérations déjà effectuées d’une transaction ■ SAVEPOINT – Identifie un point dans la transaction indiquant jusqu’où la transaction doit être défaite en cas de rollback. – Les points de sauvegarde sont indiqués par une étiquette (les différents points de sauvegarde d’une même transaction doivent avoir des étiquettes différentes). 64

Paramètres d’une transaction SET TRANSACTION [READ ONLY | READ WRITE] [ ISOLATION LEVEL READ UNCOMMITTED READ COMMITTED |REPEATABLE READ|SERIALIZABLE] ■ Le niveau d’isolation précise le degré d’interaction avec les autres transactions durant l’exécution ■ Exemple: 1. On spécifie qu'une transaction ne fera que des lectures SET TRANSACTION READ ONLY; 2. Une transaction peut lire et écrire (Option par défaut ) SET TRANSACTION READ WRITE; 3. Une transaction peut lire et écrire avec le niveau serialisable SET TRANSACTION ISOLATION LEVEL SERIALIZABLE READ WRITE 65

Conclusion ■ Le contrôle de concurrence coordonne l'exécution simultanée de transactions. ■ Trois principaux problèmes concernent l'exécution concurrente de transactions : – la perte de mise à jour, la lecture impropre, la lecture non reproductible ■ L'ordonnanceur est responsable de l'établissement de l'ordre dans lequel les opérations des transactions concurrentes sont exécutées. ■ Le verrouillage, l'estampillage et les méthodes optimistes sont utilisées par l'ordonnanceur pour assurer la sérialisabilité des transactions. ■ Un verrou garantit un accès à un objet réservé à une transaction. Le verrou empêche une transaction d'utiliser la donnée pendant qu'une autre transaction l'utilise. ■ Deux types de verrous peuvent être utilisés dans les systèmes de gestion de base de données : verrous partagés ou exclusifs. Un verrou peut avoir seulement deux états : verrouillé ou déverrouillé. 66

Conclusion ■ La sérialisabilité est garantie par l'utilisation d'un protocole de Verrouillage deuxphases soit : – une phase où la transaction pose les verroux dont elle a besoin. – une phase où la transaction retire tous les verroux sans en poser de nouveaux. ■ Quand plusieurs transactions attendent indéfiniment et mutuellement que l'une d'entre elles retire un verrou, on est en situation de deadlock. – Deux techniques de contrôle des deadlock : la prévention et la détection. ■ Le contrôle de concurrence avec la méthode d'Estampillage attribue unique estampille à chaque transaction et ordonne l'exécution de transactions en conflit avec l'ordre des estampilles, assurant ainsi la sérialisabilité. COMMIT ? 67