Gestion des transactions Introduction 1 Une des fonctions

Gestion des transactions Introduction 1. Une des fonctions importante des SGBD modernes est d’autoriser les utilisateurs d’effectuer des opérations simultanées (concurrentes) sur des données partagées de la BD. Si ces op ne sont pas sous contrôle, les accès interfèrent tôt ou tard les uns avec les autres et la BD devient incohérente. Pour éviter cela, le SGBD met en place un protocole de contrôle de simultanéité (ou de concurrence) qui empêche les accès à la BD d’interférer. 2. Une autre fonction est la récupération de la base de données ou sa restitution dans un état correct suite à une défaillance physique ou logiciel. Ces deux fonctions sont mutuellement dépendantes et sont basées sur la notion centrale de transaction. 1

Transaction • Beaucoup d'opérations sur une BD doivent être atomiques: • Transfert d'argent entre les comptes: UPDATE Compte 1 Set Val = Val -100; UPDATE Compte 2 Set Val = Val + 100; • Si seulement une de ces requêtes est exécutée, la BD perd sa consistance 2

Transactions Une transaction est une action ou suite d’actions demandée par un seul utilisateur ou un programme d’application, qui appliquée à une base de données cohérente, restitue une base de données cohérente 3

Transactions action atomique : entièrement ou pas du tout � Préservant la consistance de la BD � Comme si l'usager était isolé sur la BD : ses résultats intermédiaires (état temporairement incohérent) sont masqués aux autres transactions. � A effet durable sur la BD, une fois terminées comme prévu Modèle ACID de transactions � 4

Modélisation � � � Ø Ø Ø Une transaction T est modélisée comme une suite finie d’actions portant sur des objets. T = < (t, Ai, Oi) >/i = 1, n. t désigne le nom de la transaction (nom interne au système), Ai une opération et Oi un objet. Les opérations qui nous intéressent sont : Begin Transaction : initialiser une nouvelle transaction Commit : terminer une transaction Read : lecture de la valeur d’un objet à partir de la base et stockage de cette valeur dans l’espace de travail de la transaction ; Write : à partir d’une valeur stockée dans l’espace de travail de la transaction, écrire cette valeur dans la base pour l’objet désigné ; Rollback : annuler une transaction (défaire toutes les mises à jour effectuées par la transaction depuis son début). En ce qui concerne les objets manipulés, ça peut être une relation, un n-uplet, ou même la valeur d’un constituant (les deux premiers chez Oracles). 5

Modélisation Lorsqu’un programme émet l’action Begin transaction ceci a pour effet de créer au niveau du SGBD une nouvelle occurrence de transaction à laquelle est associée : Ø un identificateur interne ; Ø un espace de travail ; Ø et un contexte d’exécution formé d’une série de blocs de contrôle. 6

Exemple de transaction en PL-SQL BEGIN, COMMIT (validée), ROLLBACK (annulée) BEGIN TRANSACTION UPDATE Compte 1 SET Val = Val -100 IF SQLCODE <> 0 ROLLBACK ; EXIT ; UPDATE Compte 2 SET Val = Val + 100 IF SQLCODE <> 0 ROLLBACK ; EXIT; COMMIT 7

Nécessité du controle de Concurrence Pb 1 : des MAJ perdues Solde = 100 R 2 (solde) R 1 (solde) solde : = solde +200 solde : = solde +100 W 1 (solde) Solde = 200 La base 8

Exemple solde = 100 R 2 (solde) R 1 (solde) solde : = solde+200 solde : = solde +100 W 1 (solde) solde = 200 Solde = 300 W 2 (solde) La base Au lieu de 400 9

Pb 2 : dépendance non validée ou dirty read Temps t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 T 1 T 2 begin transaction read (soldex) soldex = soldex + 100 begin transaction write (soldex) read(soldex). soldex = soldex – 10 rollback write(soldex) commit soldex 100 100 200 200 190 Au lieu de 90 Solution évidente : permettre l’exécution que d’une seule transaction à la fois. Or la raison d’être du SGBD est d’atteindre un niveau optimal de simultanéité

Pb 3 : analyse incohérente T 2 calcule le total des soldes alors qu’en // T 1 transfert 10 DA de soldex à soldez Temps T 1 T 2 soldex soldey t 1 begin trans 100 50 t 2 begin trans som = 0 100 50 t 3 read (soldex) 100 50 t 4 soldex=soldex-10 som=som+soldex 100 50 t 5 write (soldex) read(soldey) 90 50 t 6 read(soldez) som=som+soldey 90 50 t 7 soldez=soldez +10 90 50 t 8 write(soldez) 90 50 t 9 commit read(soldez) 90 50 soldez 25 25 35 35 0 0 100 150 150 t 11 185 35 50 185 35 som=som+soldez commit 90 50 90 som 11

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. 12

Gestion de la concurrence Objectif : planifier les transactions de manière à éviter toute interférence entre elles et, donc d’éviter les problèmes des types précédents tout en gardant un niveau optimal de simultanéité, et de parallélisme dans le système, de sorte que les transactions puissent s’exécuter sans interférence, certes, mais surtout autant que possible en parallèle. 13

Quelques définitions � Contrôleur (scheduleur) : un module du SGBD chargé de contrôler les accès concurrents aux données. � Planification (schedule) : une séquence d’opérations d’un ensemble de transactions concurrentes qui préserve l’ordre des opérations dans chacune des transactions. � Planification sérielle est une planification où les opérations de chaque transaction sont exécutées de manière consécutive, sans aucun entrelacement avec d’autres transactions (pas de parallélisme). Ø Ces exécutions sont correctes mais peuvent donner des résultats différents (voir td). � Planification non sérielle est une planification où les opérations d’un ensemble de transactions sont exécutées de manière entrelacée. Ø Une planification non sérielle sera correcte si elle produit les mêmes résultats et a les mêmes effets sur la BD qu’une planification série des mêmes transactions et cela quelque soit l’état initial de la base de données. 14

Quelques définitions suites Principe de sérialisabilité Ne laisser s’exécuter les transactions en parallèle que celles provoquant les mêmes effets sur les données qu’une exécution en séquence de ces mêmes transactions. Définition : Un ordonnancement est correct s’il est sérialisable, c’est-à-dire équivalent à un ordonnancement série formé des mêmes transactions. Quelques résultats : Si deux transactions ne font que lire des données, elles n’entrent pas en conflit et leur ordre est sans importance. q Si deux transactions soit lisent soit écrivent des données complètement différentes, elles n’entrent pas en conflit et leur ordre est sans importance. q Si une transaction écrit dans des données et si une autre transaction lit ou écrit dans les mêmes données, alors l’ordre de leur exécution importe. q 15

Temps 1 Begin Transaction. T 1 2 Read 1(soldex) 3 Write 1 (soldex) 4 Begin Transaction T 2 5 Read 2(soldex) 6 Write 2(soldex) 7 Read 1(soldey) 8 Write 1 (soldey) 9 Commit 1 10 Read 2(soldey) 11 Write 2(soldey) 12 Commit 2 (a) Begin Transaction T 1 Read 1(soldex) Write 1 (soldex) Begin Transaction T 2 Read 2(soldex) Read 1(soldey) Write 2(soldex) Write 1 (soldey) Commit 1 Read 2(soldey) Write 2(soldey) Commit 2 (b) Begin Transaction T 1 Read 1(soldex) Write 1 (soldex) Read 1(soldey) Write 1 (soldey) Commit 1 Begin Transaction. T 2 Read 2(soldex) Write 2(soldex) Read 2(soldey) Write 2(soldey) Commit 2 (c) La planification (c) est sérielle et comme (a) et (b) équivalent à (c), (a) et (b) sont des planifications sérialisables. Ø Une planification de sérialisation (en vue de résoudre) des conflits trie les opérations conflictuelles d’une manière proche de l’exécution sérielle. 16

Test de conflits de la capacité de sérialisation Sous la règle d’écriture contrainte, un graphe de précédence peut être produit pour tester la sérialisation des conflits. Pour une planification P, un graphe de précédence est un graphe orienté dirigé G = (N, F) Construit comme suit : Ø Créer un nœud pour chaque transaction. Ø Créer une flèche dirigée Ti Tj si Tj lit la valeur d’un élément écrit par Ti Ø Créer une flèche dirigée Ti Tj si Tj écrit une valeur dans un élément après qu’il a été lu par Ti Ø Créer une flèche dirigée Ti Tj si Tj écrit une valeur dans un élément après qu’il a été écrit par Ti Si une flèche Ti Tj existe dans le graphe de précédence pour P, alors dans toute planification sérielle S’ équivalente à S, Ti doit apparaître avant Tj. Si le graphe de précédence contient un cycle, la planification n’est pas sérialisable en vue de résoudre les conflits. 17

Planification sans sérialisation des conflits La transaction T 1 transfère 100 Da d’un compte de solde vers un autre compte de solde, tandis que T 2 augmente de 10% le solde de ces deux comptes. Temps t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 t 11 t 12 t 13 t 14 T 1 Begin Transaction Read (soldex) soldex = soldex - 100 Write(soldex) Read(soldey) soldey = soldey +100 Write(soldey) Commit T 2 Begin Transaction Read(soldex) soldex = soldex * 1. 1 Write(soldex) Read(soldey) soldey = soldey * 1. 1 Write(soldey) Commit 18

T 1 T 2 Le graphe de précédence présente un cycle : la planification ne permet pas la sérialisation En pratique, un SGBD ne teste pas l’aspect sérialisable d’une planification. Ce serait irréalisable car les interférences des opérations des transactions concurrentes est surtout dicté par le système d’exploitation. Au lieu de cela, l’approche choisie consiste à faire appel à des protocoles qui selon leur réputation, produisent des planifications sérielles

Récupération La capacité de sérialisation identifie des planifications qui conservent toute sa cohérence à une base de données, en admettant qu’aucune transaction planifiée n’échoue. Si une transaction défaille, la propriété d’atomicité impose que nous annulions les effets de la transaction. En outre, la propriété de durabilité indique qu’une fois qu’une transaction est validée, il n’est plus possible d’annuler les modifications qu ’elle a apportées. Exemple diapos 18 avec un Rollback à la place du commit de la transaction T 1. Dans ce cas on doit défaire toutes ce qu’a fait T 1. Or T 2 a lu la valeur modifiée de solde x fournie par T 1 et elle a même modifié soldex, puis validé le changement. A proprement parler, nous devrions défaire la transaction T 2 aussi car elle a employé une valeur de soldex qui a été défaite. Or la propriété de durabilité ne nous le permet pas. En fait cette planification est irrécupérable Définition d’une planification récupérable: Une planification où, pour toute paire de transactions Ti et Tj, si Tj lit une donnée provenant d’une écriture préalable de Ti, alors l’opération de validation de Ti précède l’opération de validation de Tj 20

Techniques de contrôle de concurrence Il existe deux techniques de contrôle de concurrence principales qui permettent d’exécuter des transactions en parallèles en toutes sécurité, à condition de faire appel à certaines contraintes : les méthodes de verrouillage et d’estampillage. Ces méthodes sont fondamentalement conservatrices (ou pessimistes) : elles provoquent un retardement des transactions au cas où elles entreraient en conflit avec d’autres transactions dans un certain délai à venir Les méthodes optimistes reposent sur l’hypothèse que les conflits sont rares, de sorte qu’elles permettent aux transactions d e procéder de manière désynchronisée et ne vérifient la présence de conflits qu’en fin de transactions lors de leur validation. 21

Verrouillage Une procédure employée pour contrôler les accès concurrents aux données. Lorsqu’une transaction accède à la base de données, un verrou est susceptible de bloquer l’accès à d’autres transactions pour éviter de faux résultats. Les approches de verrouillage sont les plus suivies pour garantir la sérialisation des transactions concurrentes. Il existe plusieurs variantes mais elles partagent toutes la même caractéristique fondamentale : une transaction doit réclamer un verrouillage partagé (en lecture) et exclusif (en écriture) sur la donnée avant d’effectuer réellement l’opération de lecture ou d’écriture sur la base de données correspondante Le verrou empêche une autre transaction de modifier la donnée où même de la lire, dans le cas d’un verrouillage exclusif Le verrou est mis en place en pratique, soit par l’activation d’un bit dans la donnée qui indique qu’une partie de la base de données est verrouillée, soit par le maintien d’une liste des parties verrouillées de la base de données et autres…. 22

Règles de base du verrouillage Verrou partagé: Si une transaction dispose d’un verrou partagé sur la donnée, elle peut lire la donnée mais pas la modifier. Verrou exclusif : Si une transaction possède un verrou exclusif sur la donnée, elle peut lire et modifier cette donnée. Comme des opérations de lecture ne génèrent aucun conflit, il est possible que plusieurs transactions détiennent simultanément des verrous partagés sur la même donnée Par contre le verrou exclusif sur une donnée accorde à une transaction le monopole d’accès à cette donnée. Dans ce cas aucune autre transaction n’est en mesure de lire ou modifier la donnée. 23

Utilisation des verrous Toute transaction devant accéder à une donnée verrouille d’abord la donnée, demandant soit un verrouillage partagé dans le cas d’un accès en lecture, soit un verrouillage exclusif dans le cas d’un accès tant en lecture qu’en modification � Si la donnée n’est pas déjà verrouillée par une autre transaction, le verrou est accordé. � Si la donnée est déjà verrouillée par une autre transaction au moment de la demande, le SGBD détermine si la demande est compatible avec le verrou actuel. Si c’est un verrou partagé que la transaction demande, alors qu’un verrou partagé est déjà placé sur la donnée, la requête peut être satisfaite et le verrou est accordé; dans le cas contraire, la transaction demanderesse doit attendre que le verrou se libère. � Une transaction qui détient un verrou le conserve tant qu’elle ne le libère pas explicitement pendant l’exécution ou implicitement lorsqu’elle se termine (par une annulation ou une validation). Ce n’est que lorsqu’un verrou exclusif est libéré que les effets de l’opération d’écriture qui a motivé le verrou deviennent visibles aux autres transactions. � 24

Cet usage des verrous ne garantit pas la sérialisation des planifications Application des règles à l’exemple de la diapos 18 P = { verrou_écriture (T 1, soldex), lecture (T 1, soldex), écriture (T 1, soldex), déverrouillage(T 1, soldex), verrou_écriture (T 2, soldex), lecture (T 2, soldex), écriture (T 2, soldex), déverrouillage(T 1, soldex), verrou_écriture (T 2, soldey), lecture (T 2, soldey), écriture (T 2, soldey), déverrouillage(T 2, soldey), validation(T 2), verrou_écriture (T 1, soldey), lecture (T 1, soldey), écriture (T 1, soldey), déverrouillage(T 1, soldey), validation (T 1)} Si, préalablement à l’exécution, soldex = 100, soldey = 400, le résultat devrait être Ø soldex = 220, soldey = 330, si T 1 s’exécute d’abord, ou Ø soldex = 210, soldey = 340, si T 2 s’exécute avant. En fait, le résultat de la planification P devrait donner Ø soldex = 220, soldey = 340. P n’est pas une planification sérialisable. 25

Pourquoi ça ne marche pas? � Le problème de cet exemple est que la planification libère les verrous détenus par une transaction aussitôt que la lecture ou l’écriture associée a été réalisée et qu’il n’est plus utile d’accéder à l’élément sujet du verrou (par exemple soldex). Néanmoins, la transaction en elle-même verrouille encore des données (soldey) après la libération du premier verrou. Ø Donc, même si cette approche semble améliorer la simultanéité des transactions, elle permet encore à des transactions d’interférer entre elles, perdant ainsi l’isolation absolue et l’atomicité. Pour régler ce problème d’autres protocoles ont été mis en place par exemple le protocole de verrouillage en deux phases (V 2 P ou 2 PL (two_phase locking) 26

Verrouillage en deux phases : V 2 P Une transaction suit le protocole en deux phases si toutes les opérations de verrouillage précèdent la première opération de déverrouillage dans la transaction. Toute transaction est divisible en deux phases : une première phase dite de croissance où elle acquiert tous les verrous mais ne peut en libérer aucun et une phase de résorption, au cours de laquelle libère tous les verrous et ne peut plus en obtenir aucun. 27

Eviter le problème de la mise à jour perdue à l’aide du V 2 P Temps t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 T 1 T 2 begin transaction verrou-écriture(solde) Read(solde) attente solde = solde +100 attente Write(solde) attente commit/déverrouillage(solde) Read(solde) solde = solde + 200 Write(solde) commit/déverrouillage(solde) solde 100 100 200 200 400 28

Eviter le problème de la dépendance non validée à l’aide du V 2 P Temps t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 T 1 T 2 begin transaction verrou-écriture( soldex) read (soldex) begin transaction soldex = soldex + 100 verrou-écriture( soldex) write (soldex) Attente rollback/ déverrouillage(soldex) read(soldex) . soldex = soldex – 10 write(soldex) commit/ déverrouillage (soldex) soldex 100 100 200 100 100 90 T 1 est obligée d’attendre que le verrou soit libéré par T 2. Ceci n’a lieu que lorsque l’annulation de T 2 est achevée. 29

Eviter le problème de l’analyse incohérente grâce au V 2 P Time T 1 T 2 t 1 begin trans t 2 begin trans som = 0 t 3 verrou_écriture(soldex) t 4 read (soldex) verrou_lecture(soldex) t 5 soldex=soldex-10 Attente t 6 write (soldex) Attente t 7 verrou_écriture(soldez) Attente t 8 read(soldez) Attente t 9 soldez=soldez +10 Attente t 10 write(soldez) Attente t 11 commit/ déverrouillage Attente t 12 read (soldex) t 13 som=som+soldex t 14 verrou_lecture(soldey) t 15 read (soldey) t 16 som=som+soldey t 17 verrou_lecture(soldez) t 18 read(soldez) t 19 som=som+soldez t 20 commit/déverrouillage soldex 100 100 100 90 90 90 90 soldey 50 50 50 50 50 31 soldez 25 25 25 35 35 35 som 0 0 0 90 90 90 140 140 175

Il est possible de prouver que si toutes les transactions dans une planification suivent le protocole de verrouillage en deux phases, alors la planification garantit qu’elle est sérialisable pour résoudre les conflit(Eswaran et al. ) cependant, le protocole de verrouillage en deux phases ne garantit pas l’aspect sérialisable. 31

Annulations en cascade Time t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 t 11 t 12 t 13 t 14 t 15 t 16 t 17 t 18 t 19 T 1 begin transaction verrou_écriture(soldex) read(soldex) verrou_lecture(soldey) read(soldey) soldex = soldey + soldex write(soldex) déverrouillage(soldex) : : : rollback T 2 T 3 begin transaction verrou_écriture(soldex) read(soldex) soldex = soldex + 100 write(soldex) déverrouillage(soldex) : : begin-transaction verrou_lecture(soldex) rollback : rollback 32

Problème : les annulations en cascade ne sont jamais souhaitables, parce qu’elles induisent potentiellement la destruction d’un volume significatif de travail accompli. Solution : reporter la libération de tous les verrous à la fin des transactions, comme dans les exemples précédents. De cette façon, le problème précédent ne pourrait apparaître , puisque T 3 n’obtiendrait pas le verrou exclusif qu’elle exige avant que T 1 ait terminé son annulation. C’est le principe même du verrouillage rigoureux en deux phases. Dans ce cas on arrive à montrer que les transactions peuvent être mises en série dans l’ordre de leurs validations. Autre variante, le verrouillage strict en deux phases : ne retient que les verrous exclusifs jusqu’à la fin des transactions. La plupart des SGBD mettent en place une de ces deux variantes du verrouillage en deux phases Autres problème s: Ø verrous indéfinis (deadlock) : quand les deux transactions attendent l’une des verrous détenus par l’autre et vice versa. Il faut pouvoir les détecter et les résoudre. Ø Verrou infini (livelock) : quand une transaction est maintenue indéfiniment dans un état d’attente, si l’algorithme d’attente qui régit les transactions est injuste et ne tient pas compte du temps maximum d’attente des transactions Solution : mettre en place un système d’arbitrage des priorités, par lequel, plus le temps d’attente d’une transaction est long, plus forte est la priorité de cette transaction (file d’attente fifo) 33

Contrôle de concurrence et structures d’index Administration de chaque page d’index comme un élément de donnée et application du protocole v 2 p. Problème : les niveaux supérieurs d’index sont susceptibles d’accès fréquents (recherche de haut en bas) et les conflits sont quasi systématiques. Observations : Ø Le chemin de recherche part toujours de la racine de l’arborescence et descend vers les nœuds feuilles de l’arbre sans retour : qd un nœud de niveau inférieur est atteint, les niveaux supérieurs deviennent inutiles. Ø Qd une nouvelle valeur d’index (une clé et un pointeur) est insérée dans un nœud et si le nœud n’est pas plein, l’insertion ne provoque pas de changement aux nœuds de niveaux supérieurs. Ceci suggère que, dans ce cas, nous n’avons besoin de verrouiller exclusivement que le nœud feuille, et de ne verrouiller exclusivement les nœuds de niveaux supérieurs que quand un nœud est plein et qu’il faut l’éclater. 34

Contrôle de concurrence et structures d’index Stratégie de verrouillage : Ø Pour des recherches, demander des verrous partagés sur les nœuds à partir de la racine et de proche en descendant le long du chemin de recherche dans l’arborescence. Libérer le verrou sur un nœud (parent) dès qu’un verrou est obtenu sur un nœud enfant de celui-ci. Ø Dans les cas d’insertions, une approche conservatrice consiste à demander des verrous exclusifs sur tous les nœuds à mesure que nous descendons vers le nœud feuille à modifier. Ceci garantit qu’un éclatement d’un nœud enfant peut se propager du bas vers le haut, pour remonter jusqu’à la racine c’est nécessaire. Cependant, si un nœud enfant n’est pas plein, le verrou sur son nœud parent peut être libéré. � Une approche plus optimiste consisterait à demander des verrous partagés sur tous les nœuds parcourus pendant la descente jusqu’au nœud feuille à modifier. Pour ce dernier, nous demandons un verrou exclusif sur le nœud feuille même. S’il faut éclater ce nœud, nous demandons l’élévation du verrou partagé en verrou exclusif sur le nœud parent. . Nous poursuivons l’élévation si c’est nécessaire jusqu’à la racine. La probabilité de devoir éclater un nœud est généralement faible, ce qui fait de cette approche la meilleur à adopter. La technique du verrouillage d’un nœud enfant et la libération du verrou sur le parent s’appellent le couplage de verrouillage ou crabbing 35

Verrou mortel Deadlock C’est l’impasse générée par deux transactions (ou plus) qui attendent l’une, que des verrous se libèrent, alors qu’ils sont détenus par l’autre. Time T 1 T 2 t 1 begin transaction t 2 verrou_écriture (soldex) begin transaction t 3 read(soldex) verrou_écriture(soldey) t 4 soldex = soldex – 10 read(soldey) t 5 write(soldex) soldey = soldey + 100 t 6 verrou_écriture(soldey) write(soldey) t 7 Attente verrou_écriture(soldex) t 8 Attente t 9 : : Il faut que le SGBD reconnaisse la présence du verrou indéfini ou motel (deadlock)et qu’il le brise d’une manière ou d’une autre. Il n’existe malheureusement qu’une seule solution pour contrer les deadlocks : abandonner une ou plusieurs des transactions. Ceci suppose de défaire toutes les modifications apportées par la (ou les) transaction(s) annulée(s). Dans notre cas si on annule la transaction T 2, les verrous détenus par cette transaction sont libérés, T 1 pourra poursuivre son travail. 36

Verrou mortel Deadlock Le deadlock est transparent à l’utilisateur. Le SGBD relancera lui-même les transactions annulées. Trois techniques permettent de gérer les deadlocks 1. Délai impartis : c’est l’approche la plus simple et la plus pratique. Elle est utilisée par la plupart des SGBD commerciaux. L’inconvénient est que peut être que la transaction qui a dépassé le temps qui lui a été imparti, n’était pas en deadlock mais simplement en attente d’une donnée qui n’a pas encore été libéré. 2. Prévention des deadlocks (méthode d’estampillage) ou une variante de V 2 P ( le V 2 P conservateur), une transaction demande et obtient tous ses verrous au moment où elle débute et, si elle ne les obtient pas tous, attend qu’ils soient disponibles avant de démarrer effectivement. Ce protocole présente l’avantage que si la lutte est acharnée pour obtenir les verrou, le temps de conservation des verrous se trouve réduit parce que les transactions ne sont jamais bloquées et n’attendent donc pas une fois démarrées. Sauf que s’il n’y a pas beaucoup de conflits, les verrous sont détenus plus longtemps pour rien. De plus la charge de verrouillage/dévérouillage est élevée. Et si elle échoue dans l’obtention d’un verrou, elle doit libérer tous les autres déjà obtenus, puis recommencer. En pratique, une transaction n’est pas en mesure de connaître au départ les verrous dont elle aura réellement besoin et de ce fait, risque de verrouiller plus de données que nécessaire. (protocole rarement utilisé). 3. Détection des deadlocks. 37

Détection des deadlocks Construction d’un graphe des attentes indiquant les dépendances des transactions : une transaction Ti dépend d’une transaction Tj qd la transaction Tj détient un verrou sur la donnée que Ti attend. Le graphe G(N, F) est construit comme suit : � Créer un nœud pour chaque transaction. � Créer une flèche Ti Tj quand la transaction Ti attend de verrouiller un élément actuellement verrouillé par Tj Un deadlock existe ssi le graphe des attentes contient un cycle. y T 1 T 2 x 38

Fréquence de la détection des deadlocks et choix des victimes Comme un cycle dans le graphe des attentes est une condition nécessaire et suffisante pour qu’un deadlock existe, l’algorithme de détection des deadlocks génère le graphe des attentes à des intervalles réguliers dans le temps et vérifie la présence d’un cycle. Le choix de la longueur de l’intervalle entre les exécutions de l’algorithme est important. Si cet intervalle est trop court, la détection prend beaucoup du temps du processeur; s’il est trop long, les verrous risquent de ne pas être détectés dans un intervalle important. Un algorithme dynamique de détection de deadlock part avec une taille initiale d’intervalle. Chaque fois qu’aucun deadlock n’est détecté, l’intervalle de détection peut être augmenté, et à chaque fois qu’un deadlock est détecté, l’intervalle peut être réduit. Dans le cas d’un deadlock, le choix de la (les) transaction(s) victime(s) dépend : � Du temps depuis lequel la transaction s’exécute (la plus récente est moins coûteuse) � Du nombre de données modifiées par la transaction � Le nombre de données que la transaction doit encore mettre à jour. Malheureusement les SGBD ne peuvent le savoir � La victime doit avoir une priorité lors de sa relance (gestion de la famine) 39

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. Comme elles ne font intervenir aucun verrou, elles ne peuvent donner lieu à des deadlocks. Avec ces méthodes il n’y a aucune attente : les transactions qui entrent en conflit sont simplement annulées et redémarrées avec une nouvelle estampille. Les estampilles sont générées simplement à 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. Estampillage Un protocole de contrôle de concurrence qui classe les transactions dans un ordre tel que les transactions plus anciennes, qui portent les estampilles plus petites, obtiennent la plus grande priorité dans l’éventualité d’un conflit. En plus des estampilles sur les transactions, il y aussi des estampilles sur les données elles-mêmes. Chaque donnée possède une estampille de lecture indiquant l’estampille de la dernière transaction ayant lu la donnée et une estampille d’écriture indiquant l’estampille de la dernière transaction qui a effectuée une écriture sur cette donnée. 40

Protocole de classement par ordre d’estampille Soit une donnée A et Ti une transaction qui utilise A : I est l’estampille de T et EL(A) l’estampille de lecture sur A et 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 Procédure d’écriture Si (EL(A) i) et EE(A) i alors Exécuter l’écriture EE(A) : = i ; Sinon rejeter Finsi 41

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 42

Time t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 t 11 t 12 t 13 t 14 t 15 t 16 t 17 t 18 opération T 1 T 2 T 3 begin transaction read(soldex) soldex=soldex+10 write(soldex) begin tansaction read(soldey) soldey=soldey+20 Begin transaction read(soldey) write(soldey) soldey=soldey+30 soldey=soldey+20 write(soldey) soldez= 100 write(soldez) soldez= 50 soldez=50 commit read(soldez) begin transaction read(soldey) commit read(soldey) soldey=soldey+20 write(soldey) commit 43

Récupération d’une base de données Le processus de restauration de la base de données à un état correct dans l’éventualité d’une défaillance 1. Nécessité de la récupération Le stockage des données fait généralement appel à quatre types de supports différents, du moins fiable au plus fiable : la mémoire principale, les disques magnétiques, les bandes magnétiques et les disques optiques. La mémoire principale ou mémoire vive est un système de stockage volatile, qui ne résiste habituellement pas aux plantages du système. Les disques magnétiques fournissent un stockage en ligne non volatile/ à la mem principale ils sont plus fiable et bien meilleurs marché mais ils sont plus lents (environ 100 fois plus lents). La bande magnétique est un support de stockage hors ligne non volatile, beaucoup plus fiable que le disque, moins cher mais beaucoup plus lent puiqu’il ne permet que des accès séquentiels. Le disque optique est plus fiable que la bande magnétique, meilleur marché, plus rapide et permet des accès directs. La mémoire est considérée comme le composant de stockage principal, tandis que les autres forment les périphériques de stockage secondaire. Un stockage stable représente des informations dupliquées sur plusieurs supports de stockage non volatiles (généralement des disques) qui présentent des modes de défaillance différents (exemple la technologie des disques RAID). 44

Défaillances possibles Les plantages système dus aux erreurs de matériel ou de logiciels, conduisant à la perte de mémoire principale. � Les défaillances de supports de données, telles que cassures de tête de lecture ou les supports illisibles entraînant la perte de parties du stockage secondaire � Les erreurs de logiciel d’application, telles que les erreurs logiques dans un programme qui accède à la base de données, provoquant la défaillance d’une ou plusieurs transactions. � Les catastrophes naturelles, comme les incendies, les inondations, les tremblements de terre ou de coupures d’alimentation électrique � Le manque de soin ou la destruction non intentionnelle des données ou des utilitaires par les opérateurs ou les utilisateurs. � Le sabotage, cad, la corruption ou la destruction intentionnelle des données du matériel ou des utilitaires logiciels. Quelque soit la cause de la défaillance, nous devons tenir compte de deux de ses effets : la perte de la mémoire principale, y compris des tampons de base de données et la perte de la copie sur disque de la base de données. Objectif : réduire ces effets et récupérer le plus de données possible. � 45

Les transactions représentent l’unité de récupération. A suivre… 46

? T I M M CO 47