45
Administratio n des bases de données Chapitre 5: Gestion des transactions et gestion des accès concurrents

Administration des b ases de données

  • Upload
    kellan

  • View
    23

  • Download
    0

Embed Size (px)

DESCRIPTION

Administration des b ases de données. Chapitre 5: Gestion des transactions et gestion des accès concurrents. Agenda. Introduction Transaction et contrôle de transaction Gestion des accès concurrents Consistance de données Mécanisme de verrouillage Conclusion. Introduction. - PowerPoint PPT Presentation

Citation preview

Page 1: Administration des b ases de données

Administration des bases de données

Chapitre 5: Gestion des transactions et gestion des accès concurrents

Page 2: Administration des b ases de données

2

Agenda

Introduction Transaction et contrôle de transaction Gestion des accès concurrents Consistance de données Mécanisme de verrouillage Conclusion

Page 3: Administration des b ases de données

3

Introduction

Une BD peut être manipulée simultanément par plusieurs users ce qui implique une utilisation concurrente des BDs partagées

Certaines contraintes doivent être assurées par le SGBDR:– Une bonne disponibilité de l’information,– Une garantie de la cohérence des datas,– Et une gestion du conflit d’accès.

Pour assurer cette cohérence, nous aborderons les concepts de transaction et d’accès concurrents.

Page 4: Administration des b ases de données

Partie n°1

Gestion des transactions

Page 5: Administration des b ases de données

5

Objectifs

Ce qu’est une transaction Pourquoi il est important de gérer les

transactions dans les BDs Quels sont les principaux protocoles de

gestion de transaction Comment écrire une transaction avec Oracle Comment les transactions sont gérées dans

Oracle

Page 6: Administration des b ases de données

6

Transaction

Définition– Une transaction est une unité logique de traitement formée d’une suite

d’opérations (interrogation (lecture R) et/ou modification (écriture W) de la BD)

– Cet ensemble d’opération doit être soit validé, soit annulé– Exemple : Environnement bancaire, transfert d’une somme S d’un compte

C1 à un compte C2.(1)   Début transaction(2)   R(C1)(3)   C1 = C1 – S(4)   W(C1)(5)   R(C2)(6)   C2 = C2 + S(7)   W(C2)(8)   Fin de transaction.

– Dans cet environnement, soit toutes les actions sont effectuées (transfert réussi), soit toutes annulées (pas de transfert)

Page 7: Administration des b ases de données

7

Contrôle de transaction 1/5

Le contrôle de transaction consiste à définir :– Le début et la fin de la transaction– Et le découpage de la transaction en sous transactions dans

le cas où le nbre d’opérations composant la transaction est important.

Début et la fin de transaction– Une transaction démarre par

• N’importe quel ordre SQL suivant la connexion à Oracle• Ou par la fin de la transaction précédente

– La fin d’une transaction peut être définie soit de façon• Explicite par l’un des ordres COMMIT ou ROLLBACK• Ou implicite

Page 8: Administration des b ases de données

8

Contrôle de transaction 2/5

Fin de transaction explicite– COMMIT termine une transaction

• En validant les datas,• En rendant définitives et accessibles aux autres users

toutes les modifications effectuées pendant la transaction en les sauvegardant dans la BD,

• Et en annulant tous les verrous positionnés pendant la transaction

– ROLLBACK termine une transaction • En annulant toutes les modifications de datas ,• Et en annulant tous les verrous positionnés pendant la

transaction

Page 9: Administration des b ases de données

9

Contrôle de transaction 3/5

Fin de transaction implicite– L’exécution d’un ordre de LDD(create,

drop, alter) après un ordre de LMD(insert, update, delete) valide la transaction en cours.

– L’arrêt normal d’une session par un EXIT permet la validation en cours.

– L’arrêt anormal d’une session annule la transaction en cours.

Page 10: Administration des b ases de données

10

Contrôle de transaction 4/5

Transaction avec étapes intermédiaires– Le découpage d’une transaction en

plusieurs parties se fait en insérant des points de repères.

– Ce découpage permet soit :• De valider l’ensemble des mises à jour,• Soit d’annuler tout ou une partie des maj.

– La création d’un point de repère se fait par l’ordre SAVEPOINT point_de_repère

Page 11: Administration des b ases de données

11

Contrôle de transaction 5/5

Transaction avec étapes intermédiaires -Exemple– Update table; Insert into table; Savepoint a Delete from table; Savepoint b Rollback to a Insert into table; Commit

Quels sont les ordres SQL qui seront, définitivement, pris en considération ?

Page 12: Administration des b ases de données

12

Propriétés des transactions (ACID)

Atomicité– Toutes les mises à jour

doivent être effectuées ou aucune.

– Exemple :

Begin CEpargne = CEpargne –

3000 CCourant = CCourant +

3000 Commit T1

Annulation du débit !!

Durabilité– Les modifications d’une

transaction validée ne seront jamais perdue

– Exemple :

Begin CEpargne = CEpargne –

3000 CCourant = CCourant +

3000 Commit T1

S’assurer que le virement a été bien fait !!

Crash disque

Panne

Page 13: Administration des b ases de données

13

Propriétés des transactions (ACID)

Cohérence– La transaction doit faire

passer la BD d'un état cohérent à un autre.

– Exemple : Cohérence des opérations

Isolation– Les résultats d'une

transaction ne sont visibles aux autres transactions qu'une fois la transaction validée.

N°Compte1024921738512...

Solde1000-400357250

Programme 1 : calculer le total des soldes

Programme 2: transférer 100 du compte 1024au compte 512

Alors que le programme 1

en est au compte N°738, le programme 2 fait le transfert

Page 14: Administration des b ases de données

14

Échéanciers

Un échéancier – est une suite d’opérations (de

lecture (R), d’écriture (W), de validation (C) ou d ’abandon (A)), réalisées au cours d’un ensemble de transactions et ordonnées dans le temps

Cet échéancier n’est pas complet car aucune des deux transactions n’est validée ou abandonnée

T1 T2R(A)W(A)

R(B)W(B)

R(C)W(C)

Page 15: Administration des b ases de données

15

Sérialisabilité

Un échéancier est sérialisable ssi :– l’effet de l’exécution de l’échéancier est identique

à l’effet de l’exécution en série des transactions qui le composent

Notons que :– différentes exécutions en séries peuvent amener à

différents résultats que l’on considèrera tous comme acceptables, la BD n’assure pas un résultat plutôt qu’un autre

Notre objectif : avoir des transactions sérialisables

Page 16: Administration des b ases de données

Partie n°2

La gestion de concurrence

Page 17: Administration des b ases de données

17

Objectifs

Permettre l’exécution simultanée d’un grand nombre de transactions

Régler les conflits lecture/écriture Garder de très bonne performance Eviter les blocages

Page 18: Administration des b ases de données

18

Concurrence

Définition– Il y a Accès Concurrent (AC) lorsque plusieurs

transactions (Tr) accèdent à la même data dans la BD.

– La Gestion des Accès Concurrents (GAC) consiste à s’assurer que l’exécution simultanée d’un {Tr1,…Trn} qui accèdent à la même data dans la BD produit le même résultat que si les Tri avaient été exécutées en séquence c’est à dire que l’échéancier est belle bien sérialisable.

– La GAC repose sur les concepts de• Consistance• Intégrité des datas

Page 19: Administration des b ases de données

19

Problèmes posés par les AC 1/3

Interférence : – Il y a une interférence entre 2 transactions

T1 et T2 si le résultat de l’exécution de T1 et T2 en // est de celui de l’exécution en série de T1 et T2.

Cette interférence engendre soit :– Une perte de mise à jour– Ou une lecture impropre

Page 20: Administration des b ases de données

20

Problèmes posés par les AC 2/3

Exemple de perte de mise à jourOpération n°1 Temps Opération n°2 État de la base

Qte=1000

Lire qte 1

2 Lire qte

Qte:=qte+500 3 Qte=1500

Écrire qte 4

5 Qte:=qte+3000

6 Écrire qte Qte=4000

Résultat : 500 unités perdues

Page 21: Administration des b ases de données

21

Problèmes posés par les AC 3/3

Exemple de lecture impropreOpération n°1 Temps Opération n°2 État de la base

Qte=1000

Lire qte 1

Qte:=qte+500 2

Écrire qte 3 Qte=1500

4 Lire qte

5 Qte:=qte+3000

6 Écrire qte Qte=4500

Annuler transaction 8 Qte=4500

Résultat : 500 unités de trop

Page 22: Administration des b ases de données

22

Comment résoudre le problème d’interférence? Ce problème a été résolu grâce aux

concepts:– Consistance des datas : il y a consistance lorsque

le système garantit que les datas utilisées par le query ne sont pas modifiées par d’autres opérations pendant toute la durée de l’exécution de ladite query.

– Intégrité : l’intégrité est assurée lorsque la base passe d’un état cohérent à un autre état cohérent après la maj.

Page 23: Administration des b ases de données

23

Consistance des datas

En consultation– Un user exécutant un SELECT sur une table ou +sieurs est

sûr de voir toutes les datas telles qu’elles étaient au début de la transaction même si d’autres users modifient la table et valident leurs modifications pendant ce temps.

– Pour cela, le SGBDR enregistre la date de début de la Tr

En mise à jour– Les modifications des datas non validées par un COMMIT

sont visibles uniquement à l’intérieur de la transaction en cours (propriété d’isolation d’une Tr). Elles sont accessibles aux autres users qu’après la validation de la transaction.

Page 24: Administration des b ases de données

24

Principe de la consistance de datas

Col A Col B

Ali 10

Med 20

Moez 30

Toutes les Tr lisent les datas de la table

Col A Col B

Ali 10

Med 60

Moez 30

Col A Col B

Ali 10

Med 60

Moez 30

TrA modifie un enregistrement, l’ancienne valeur est placée dans le rollback segment

20 20

TrA lit la data modifié,

TrB lit l’ancienne valeur

TrA TrB

Page 25: Administration des b ases de données

25

Principe de la consistance de datas Validation de la TrA

– C’est juste qu’après la validation de la TrA que les modifications deviennent permanents

– Rollback segment et verrous seront libérés– Seules les ordres qui ont débuté après la validation

accèdent aux datas modifiés– Tous les autres accèdent aux datas conservées dans le

Rollback segment

Annulation de la TrA – Les datas écrites dans le Rollback segment viennent

écraser les datas modifiés– Rollback segment et verrous seront libérés

Page 26: Administration des b ases de données

26

Mécanismes de verrouillage

La consistance est assurée grâce aux mécanismes de verrouillage.

Ces mécanismes garantissent la réservation temporaire de ressources à une transaction.

Un SGBDR offre plusieurs niveaux de verrouillage, appelés granularité:– Logique, sur table ou sur une ligne– Physique, sur segment, fichier ou page

Page 27: Administration des b ases de données

27

Mécanismes de verrouillage

Oracle8 n’offre que le niveau logique:– Verrouillage au niveau de la ligne (type TX).

• Juste les lignes modifiées par la transaction sont verrouillées

• On doit disposer de l’option TPO (Transaction Processing Option), mise en œuvre par le paramètre ROW_LOCKING=ALWAYS du fichier init.ora

– Verrouillage au niveau de la table (type TM)• Toutes les lignes de la table sont verrouillées• Les autres transactions continuent à consulter les datas

de la table, y compris ceux qui sont modifiées

Page 28: Administration des b ases de données

28

Mécanismes de verrouillage

On peut utiliser les verrous pour verrouiller:– Les datas : (data locks ou DML) DML protègent

les datas de l’user.– Le dictionnaire de datas (dictionary lock) : ce qui

permet de protéger la description des structures de datas

• La définition de la table ne peut pas être modifiée pendant une transaction

– Les Objets systèmes (SGA, buffer,…). Ce qu’on appelle par verrous internes (latches)

• Automatiques

Page 29: Administration des b ases de données

29

Les différents types de verrouillage

Les verrous TX (ligne) et TM (table) sont aussi classés selon deux catégories:– Verrou exclusif

– Verrou partagé Alors, les différents type de verrouillage sont:

– Verrouillage exclusif de la table (X)

– Verrouillage de la table en mode partagé (S)

– Verrouillage sélectif des lignes (RS)

– Verrouillage exclusif des lignes (RX)

Verrou exclusif Verrou partagé

Verrou ligne RX RS

Verrou table X S

Page 30: Administration des b ases de données

30

Mise en œuvre des verrous Verrouillage implicite géré par le SGBDR. Ce type de verrouillage

assure la consistance et l'intégrité des données– INSERT, UPDATE et DELETE posent automatiquement un verrou RX

sur la table concernée.– SELECT ne demande jamais de verrou. Possibilité d’exécuter un

SELECT sur une table même si il y a des verrous sur la table ou sur ses lignes.

– SELECT … FOR UPDATE permet de réserver, en vue d’une maj ultérieure, les lignes qui sont consultées. Un verrou RS est allouée donc sur la table

Verrouillage explicite par la commande LOCK– En complément du verrouillage implicite, nous pouvons définir une

stratégie de verrouillage. – Il est fortement déconseillé d’utiliser le LOCK TABLE car le verrouillage

automatique d’Oracle (à partir de 6.x) est plus performant que le mode manuel

Page 31: Administration des b ases de données

31

Verrouillage exclusif de la table (X)

C'est le mode le plus restrictif, il assure aux Tr qui l'obtient un accès exclusif en écriture sur une table par la commande :

LOCK TABLE table IN EXCLUSIVE MODE;

Opérations – Seule une Tr peut avoir un accès en mode X pour une table

– Les autres Tr peuvent consulter les datas de la table mais ne peuvent ni les modifier, ni poser des verrous sur la table et sur ses lignes.

Page 32: Administration des b ases de données

32

Verrouillage de la table en mode partagé (S)

Commande– LOCK TABLE table IN SHARE MODE;

Opérations – Les autres Tr peuvent mettre différents

verrous en mode partagé sur la table (RS ou S)

– Une Tr qui verrouille une table en mode S empêche les autres transactions de demander des verrous de type SRX ou X.

Page 33: Administration des b ases de données

33

Verrouillage sélectif des lignes (RS)

Il est acquis de manière automatique si l'une des commandes SQL suivante est exécuté: – SELECT ... FROM table ... FOR UPDATE OF ... ;– LOCK TABLE table IN ROW SHARE MODE;

Opérations – Ce verrou est le moins contraignant.– Il permet aux autres Tr de mettre à jour les datas

autres que celles concernées par la Tr qui a demandé le verrou (RS).

– En revanche, aucune autre transaction ne peut demander de verrou de type X.

Page 34: Administration des b ases de données

34

Verrouillage exclusif des lignes (RX)

Ce mode est acquis de façon automatique pour une table modifiée par l'une des instructions suivantes :

INSERT INTO table ...;

UPDATE table ...;

DELETE FROM table ...;

LOCK TABLE table IN ROW EXCLUSIVE MODE;

Opérations:– Ce mode empêche d'autres Tr de verrouiller manuellement la

table en mode S, X ou SRX

– La Tr qui a mis le verrouillage peut modifier un ou plusieurs les lignes de la table

Page 35: Administration des b ases de données

35

DML Locks

Le tableau suivant résumera les combinaisons possibles des divers modes de verrouillage que peuvent demander des transactions simultanées sur la même table.

Verrou obtenu par une transaction

Verrous impossibles pour les autres

transactions

Verrous possibles pour les autres transactions

X RS, RX, S, X

S RX, X RS, S

RX S, X RX, RS

RS X RS, RX, S

Page 36: Administration des b ases de données

36

Gestion des verrous

Le gestionnaire de verrou maintient une table de verrous qui contient pour chaque objet sur lequel il y a un (ou des) verrou(s) :– le nombre de transactions portant sur l’objet– la nature des verrous (partagé ou exclusif)– un pointeur vers une queue de demandes de verrous

Le SGBD maintient aussi la description des transactions dans une table des transactions qui contient :– des pointeurs vers une liste de verrous posés par chaque

transaction

Page 37: Administration des b ases de données

37

Contrôle de concurrence : Protocole de S2PL Le protocole de verrou «Strict 2-Phase

Locking» est basé sur deux règles :– Si une transaction T veut lire (resp.

modifier) un objet, il demande d’abord un verrou partagé (resp. un verrou exclusif) sur l’objet

– Tous les verrous posés par une transaction sont relâchés lorsque la Tr se termine

Page 38: Administration des b ases de données

38

Contrôle de concurrence : Protocole de S2PL

T1 T2R(A)W(A)

R(A)W(A)R(B)W(B)Commit

R(B)W(B)Commit

T1 T2X(A)R(A)W(A)X(B)R(B)W(B)Commit

X(A)R(A)W(A)X(B)R(B)W(B)Commit

Sans verrou Protocole S2PL

Page 39: Administration des b ases de données

39

Contrôle de concurrence : Protocole de S2PL Limite du protocole S2PL:

– Temps d’attente pour la Tr qui n’a pas obtenu en premier le verrou

Nécessité donc d’un autre protocole qui ne pénalise pas les Tr

Page 40: Administration des b ases de données

40

Contrôle de concurrence : Protocole de 2PL Le protocole de verrou «2-Phase Locking» est basé

aussi sur deux règles :– Si une transaction T veut lire (resp. modifier) un objet, il

demande d’abord un verrou partagé (resp. un verrou exclusif) sur l’objet

– Une transaction peut relâcher un verrou avant de se terminer, mais elle ne peut plus redemander de verrou une fois qu’elle en a relâché un

Toute Tr est alors composée de deux phases :– la phase croissante : demandes de verrous– la phase décroissante : relâchements de verrous

• une Tr ne relâche un verrou sur un objet que si elle est sûre que celui-ci ne sera plus utilisé (ni en lecture ni en écriture)

• une Tr ne relâche les verrous sur un objet que si elle est sûre que plus aucun verrou ne sera posé sur les autres objets

Page 41: Administration des b ases de données

41

Contrôle de concurrence : Protocole de 2PL

T1 T2R(A)W(A)

R(A)W(A)R(B)W(B)Commit

R(B)W(B)Commit

T1 T2X(A)R(A)W(A)X(B)Rel(A)

X(A)R(A)W(A)

R(B)W(B)Rel(B)Commit

T1 T2X(B)Rel(A) R(B)W(B)Rel(B)Commit

...

...

Sans verrou Protocole 2PL

Page 42: Administration des b ases de données

42

Contrôle de concurrence :deadlock

T1 T2X(A)W(A)

X(B)

W(B)X(A)

Avec le S2PLConflit WW classique

T1 T2W(A)

W(B)W(A)

CommitW(B)Commit

T1 T2X(A)W(A)

X(B)W(B)X(A)Rel(B)

Avec le 2PL

Impossible que T2 met un verrou sur A puisque T1 a déjà mis un verrou exclusif sur A : Blocage

Pour pouvoir relâcher le verrou sur B, T2 doit mettre un verrou sur A, ce qui est impossible puisque T1 a déjà mis un verrou exclusif sur A : Blocage

Page 43: Administration des b ases de données

43

Contrôle de concurrence: Deadlock

Problème de deadlock (DL) – Un DL peut survenir quand deux ou +sieurs users sont en

attente d'une ressource mutuellement verrouillée par chacun d'entre eux,

– Oracle détecte automatiquement les DL et le résout par l'annulation de l'une des commandes qui l'a entraîné

– un message est envoyé aux Tr concernées. C'est la Tr qui détecte en premier le DL qui est annulée.

Graphe d’attente– chaque noeud identifie une transaction active– il y a un arc de Ti vers Tj ssi Ti attend que Tj aie relâché un

verrou pour continuer– si le graphe contient un cycle, il y a DL

T1

T2

T3

Page 44: Administration des b ases de données

44

Résolution du DL

Prévention versus Détection?– Prévention

• définir des critères de priorité de sorte à ce que le problème ne se pose pas

• exemple : priorité aux transactions les plus anciennes ou priorité aux transactions qui ont le plus de verrous

– Détection• gérer le graphe des attentes• lancer un algorithme de détection de circuits dès qu’une

transaction attend trop longtemps• choisir une victime qui brise le circuit

Page 45: Administration des b ases de données

45

Contrôle de concurrence sans verrou Contrôle de concurrence par

estampillage :• Chaque transaction reçoit une date de début

(estampillage)

• Si une action ai de la transaction Ti est en conflit avec l’action aj de la transaction Tj et TS(Ti) > TS (Tj) alors Ti est abandonnée