cours bd 5bis

IntroductionDeclencheursTransactions

Bases de donneesCours 6 : Concepts avances : Declencheurs, Transactions,

Controle de concurrence

Odile PAPINI

ESILUniversite de la [email protected]

http://pages-perso.esil.univmed.fr/papini/

Odile PAPINI Bases de donnees


Plan du cours

1 Introduction

2 Declencheurs

3 Transactions



Bibliographie

Livres :

G. Gardarin : Bases de donnees objet et relationnel. Eyrollesed. 1999.

C. J. Date : Introduction aux bases de donnees. (8ie`meedition). Vuibert ed. 2004.

H. Garcia-Molina, J. D. Ullman, J. Widow : Databasesystems, the complete book. Prentice Hall ed. 2002.

Supports de cours :

Support de cours : J. Le Maitre :http ://lemaitre.univ-tln.fr/cours.htm

Support de cours : C. Sabatier, Universite de la Mediterranee.

Support de cours : N. Durand, ESIL, Dpt INTERNET

Support de cours : A. Cornuejols : www.lri.fr/ antoine



Declencheurs

Definition

Un declencheur est une re`gle, dite active, de la forme :eve`nement-condition-action

Trigger : procedure stockee qui est declencheeautomatiquement par des evenements specifies par leprogrammeur et ne sexecutant que lorsquune condition estsatisfaite

Declencheur ou Trigger est active par une requete de mise a`jour



Declencheurs

il permet :

La possibilite deviter les risques dincoherence dus a` lapresence de redondance

Lenregistrement automatique de certains evenements

La specification de contraintes liees a` levolution de donnees(ex : un salaire ne peut quaugmenter)

De definir toutes re`gles complexes liees a` lenvironnementdexecution (ex : restrictions sur des horaires, des utilisateurs)



Declencheurs

Principe dun declencheur

Sequence evenement-Condition-Action :

Trigger declenche par un evenement, specifie par leprogrammeur Insertion, destruction, modification sur une table

Le trigger teste une condition : si cette dernie`re nest pasverifiee, alors lexecution sarrete

Laction est realisee (toutes operations sur la base de donnees)



Declencheurs

Caracteristiques dun declencheur

Concernant laspect action :

SQL nest pas procedural

Les SGBD fournissent une extension du langage SQLinstructions de branchement conditionnel, instructions derepetition, affectations,

Langage imperatif permettant de creer des veritablesprocedures (procedures stockees) :

PL/SQL pour ORACLET-SQL pour SQL Servernorme SQL2003 pour DB2 et MySQL5



Declencheurs


Concernant laspect action :

Manipulation simultanee de lancienne et de la nouvelle valeurdun attribut (permet tests sur levolution)

Un trigger peut etre execute :

Une fois pour un seul ordre SQLOu a` chaque ligne concernee par cet ordre

Laction peut etre realisee avant ou apre`s levenement



Declencheurs


Il ne peut y avoir quun seul trigger par evenement sur unetable

Les triggers permettent de rendre une base de donneesdynamique

Une operation peut en declencher dautres, qui elles-memespeuvent entraner en cascade dautres triggers

Ce mecanisme nest pas sans danger

a` cause de risque de boucle infinie



Declencheurs

Creation dun declencheur (1)

Specifier levenement qui declenche laction en indiquant letype de la mise a` jour (INSERT, UPDATE, DELETE), le nomde la table et eventuellement le nom des attributs mis a` jour

Indiquer si laction est realisee avant ou apre`s eventuellement,donner un nom a` lancien et au nouveau n-uplet (uniquementle nouveau en cas dinsertion et uniquement lancien en cas desuppression)



Declencheurs

Creation dun declencheur (2)

Decrire la condition sous laquelle se declenche levenementsous la forme dune expression SQL booleenne, c.-a`-d. uneexpression pouvant etre placee dans une clause WHERE

Decrire laction a` realiser sous la forme dune procedureIndiquer si laction est realisee pour chaque n-uplet mis a` jourou une seule fois pour la requete



Declencheurs

Creation dun declencheur : exemple

Verification quun prix ne peut baisser

CREATE OR REPLACE TRIGGER prixNePeutDiminuerBEFORE UPDATE OF prixUnitaire ON ArticleFOR EACH ROWWHEN (OLD.prixUnitaire > NEW.prixUnitaire)BEGIN raise application error(-20100, le prix dun produit ne peutdiminuer) ; END ;



Declencheurs

Creation dun declencheur : exemple

Declencheur inserant un enregistrement a` linterieur dune secondetable table2 lorsquune operation dinsertion sest accompliedans une premie`re table table1.

il verifie aussi si le nouveau n-uplet posse`de un attribut attr1superieur ou egal a` 10

CREATE TRIGGER declencheur1AFTER INSERT ON table1FOR EACH ROWWHEN (NEW.attr1 >= 10)BEGININSERT INTOtable2 VALUES( :NEW.attr1, :NEW.attr2) ; END ;



Transactions : introduction

SGBD multi-utilisateurs

souvent des centaines, voire des milliers dutilisateurs

ex : syste`mes de reservation (compagnies aeriennes),operations bancaires

contraintes de temps reel

Comment eviter les interactions negatives entre les utilisateurs

et garantir la coherence de la base de donnees ?



Transactions

Transaction

sequence dinstructions SQL

souvent delimitee par des instructions de debut et de fin detransaction

Operations elementaires dacce`s a` la base de donnees :

read x : lecture dune donnee

lit un ele`ment x et le stocke dans une variable du programme

write x : ecriture dune donnee

ecrit la valeur de la variable de programme x et le stocke dansele`ment de donnees x



Transactions

Exemple de transaction : transfert dune somme S dun compte Avers un compte B

T

start

read A

A = A - S

write A

read B

B = B + S

write B

commit



Transactions

transactions concurrentes

Plusieurs transactions peuvent se derouler en meme temps

Un SGBD doit assurer que toute transaction posse`de les proprietessuivantes (ACID)

proprietes ACID

Atomicite : une transaction est une unite atomique detraitement

Coherence : une transaction preserve la coherence de la BD

Isolation : les executions des transactions ne doivent pasinterferer les unes avec les autres

Durabilite : les changements appliques a` la BD par unetransaction validee doivent persister (meme suite a` unedefaillance)



Transactions : proble`mes dus a` la concurrence

Si aucun controle du deroulement des transactions : proble`mes

perte de mise a` jour

lecture impropre

lecture de donnees incoherenteslecture de donnees non confirmees

lecture non reproductible

objets fantomes



Transactions : proble`mes dus a` la concurrence (1)

Perte de mise a` jour

T1 T2 BD

A = 10

read A

read A

A = A + 10

write A A = 20

A = A + 50

write A A = 60

On devrait avoir A= 70 MAIS on a A = 60 :perte de la mise a` jour de T1




Lecture impropre (donnees incoherentes)

T1 T2 BD

Contrainte A + B = 200

A = 120 B = 80

read A

A = A - 50

write A A = 70

read A

read B

display A +B (150 est affiche)

read B

B = B + 50

write B B = 130

T1 est coherente MAIS T2 devrait afficher la valeur 200 :lordre des operations est tel que T2 affiche 150




Lecture impropre (donnees donnees non confirmees)

T1 T2 BD

A = 50

A=70

write A A=70

read A (60 est lu)

rollback A = 50(la valeur initiale de A est restauree)

T1 a lu une valeur de A incorrecte :tout doit se passer comme si T2 navait jamais change A




Lecture non reproductible

T1 T2 BD

A = 10

read A (10 est lu)

A = 20

write A A=20

read A (20 est lu)

T2 qui ne modifie pas A doit obtenir a` chaque lecture la memevaleur pour cette donnee :

Mais lordre des operations est tel que T2 lit 10 puis 20




Objet fantome

T1 T2 BD

E = { 1, 2, 3 }

display card(E)3 est affiche

insert 4 into E E = { 1, 2, 3, 4 }

display card(E)4 est affiche

T1 na pas vu lajout de 4 dans E par T2, pour T1 4 est un objetfantome



Transactions : controle de concurrence

Resolution des proble`mes de concurrence : serialisation

serialisation

Les acces simultanes aux memes objets de la BD doivent etreserialises pour que les utilisateurs travaillent les unsindependamment des autres

Un ensemble de transactions concurrentes est correctementsynchronise si leur execution sequentielle gene`re un etat de la BDidentique a` celui qui serait obtenu si elles etaient executeesindependamment (par un seul utilisateur)




execution en serie :

Lexecution dun ensemble de transactions est dite en serie si, pourtout couple de transactions, tous les evenements de luneprece`dent tous les evenements de lautre.

executions equivalentes

Deux executions dun meme ensemble de transactions sontequivalentes ssi :

elles sont constituees des memes evenements,

elles produisent le meme etat final de la BD et les memesresultats pour les transactions :

les lectures produisent les memes resultatsles ecritures sont realisees dans le meme ordre




Definition de de la seriabilite

Une execution concurrente dun ensemble de transactions est diteserialisable ssi il existe une execution en serie equivalente




Conditions de la serialibilite :

Deux operations sont dites conflictuelles si elles appartiennenta` deux transactions differentes et si elles ne sont paspermutables

Deux operations appartenant a` deux transactions differentessont conflictuelles si et seulement si elles portent sur la memedonnee et que lune des deux au moins est une operationdecriture

Une execution concurrente est serialisable si elle peut etretransformee en une execution en serie equivalente par unesuite de permutations doperations non conflictuelles




Permutations doperations :

Les operations suivantes peuvent etre permutees sans proble`me :

lecture, lecture

operations sur des donnees differentes

Operations non permutables si meme donnee :

lecture, ecriture

ecriture, lecture

ecriture, ecriture




exemple

T1 T2

read A

write A

read A

read B

write A

write B

read B

write B

T1 T2

read A

write A

read B

write B

read A

write A

read B

write B




Test de seriabilite

graphe de precedence :

Chaque noeud est une transaction

Chaque arc indique une precedence doperations conflictuelles

condition de seriabilite :

Si le graphe posse`de un cycle, lexecution nest pas serialisable




Resolution des proble`mes de concurrence : verrouillage des

donnees

Synchronise les acce`s aux donnees des bases

De`s quune transaction acce`de a` des donnees, elle utilise unverrou

Degrade les performances de la base de donnees

A utiliser avec parcimonieLe moins longtemps possible




Le verrouillage est la technique la plus classique pour resoudre lesproble`mes dus a` la concurrence :

Avant de lire ou ecrire une donnee une transaction peutdemander un verrou sur cette donnee pour interdire auxautres transactions dy acceder

Si ce verrou ne peut etre obtenu, parce quune autretransaction en posse`de un, la transaction demandeuse estmise en attente




Afin de limiter les temps dattente, on peut jouer sur :

la granularite du verrouillage : pour restreindre la taille de ladonnee verrouillee

le mode de verrouillage : pour restreindre les operationsinterdites sur la donnee verrouillee




Granularite du verrouillage

On peut verrouiller :

une valeur dattribut,

un n-uplet (donc toutes ses valeurs),

une table (donc toutes ses lignes),

la BD (donc toutes ses tables).




Les modes de verrouillage varient dun SGBD a` lautre :

Deux modes sont toujours definis :

partage (S) : demande avant de lire une donneeexclusif (X) : demande avant de modifier une donnee

re`gles qui regissent ces deux modes

Un verrou partage ne peut etre obtenu sur une donnee que siles verrous deja` places sur cette donnee sont eux memepartages

Un verrou exclusif ne peut etre obtenu sur une donnee que siaucun verrou nest deja` place sur cette donnee




Deux operations atomiques sont utilisees pour manipuler lesverrous :

lock m (A) : demande dun verrou en mode m sur la donnee Aavec m :

X pour exclusifS pour shared

unlock (A) : deverrouillage de la donnee A




Transaction est bien formee :

Une transaction est bien formee si :

elle obtient un verrou sur une donnee avant de lire ou decrirecette donnee

elle libe`re tous ses verrous avant de se terminer

Transaction a` deux phases

Une transaction est a` deux phases si elle est bien formee et si apre`savoir libere un verrou elle nen acquiert plus




Transaction a` deux phases :

une phase dacquisition des verrous

une phase de liberation des verrous




Transaction a` deux phases :

Il est demontre que lexecution dun ensemble de transactionsa` deux phases est serialisable :

consequence il ne peut y avoir ni pertes de mise a` jour, nilectures impropres, ni lectures non reproductibles

Les transactions sont serialisees dans lordre du debut de leurphase de liberation



Transactions : plus de perte de mise a` jour

T1 T2 BD

A = 10

lock X A

read A

lock X A

A = A + 10 attente

write A attente A = 20

unlock A attente

read A

A = A + 50

write A A = 70

unlock A



Transactions : plus de lecture non reproductible

T1 T2 BD

Contrainte A + B = 200

A = 120 B = 80

lock X A

read A

A = A - 50

write A A = 70

lock S A

lock X B attente

read B attente

B = B + 50 attente

write B attente B = 130

unlock A attente

read A

unlock B

lock S B

read B

display A +B (200 est affiche)



Transactions : plus de lecture impropre

T1 T2 BD

A = 50

lock X A

A=70

write A A=70

lock S A

attente rollback A = 50(la valeur initiale de A est restauree,

A est deverouille)

read A(50 est lu)



Transactions : plus de lecture non-reproductible

T1 T2 BD

A = 10

lock S A

read A (10 est lu)

lock X A

attente read A (10 est lu)

attente unlock A

A = 20

write A A=20



Transactions : les n-uplets fatomes

T1 T2

SELECT COUNT(*)FROM livre

WHERE annee = 2003 ;(re`ponse n)

INSERT INTO livreVALUES(Les BD, 203)

COMMIT

SELECT COUNT(*)FROM livre

WHERE annee = 2003 ;(re`ponse n+1)COMMIT



Transactions : plus de n-uplets fatomes

T1 T2

lock S livreSELECT COUNT(*)

FROM livreWHERE annee = 2003 ;

(re`ponse n)

lock X livreSELECT COUNT(*) attente

FROM livre attenteWHERE annee = 2003 ; attente

(re`ponse n) attenteCOMMIT attente

INSERT INTO livreVALUES(Les BD, 203)

COMMIT

exemple Odile PAPINI Bases de donnees



inconvenient de la technique de verrouillage : risque inter-blocage

T1 T2

lock X A

lock X B

lock S B

attente lock S A

attente attente

situation dinter-blocage : cycle dans le graphe dattente destransactions




resolution de linter-blocage :

Prevention :Tous les verrous dont une transaction a` besoin lui sont fournisau debut

Detection : Si cycle dans le graphe dattente interblocage : ondefait une des transactions bloquees et on la relance plus tard

Plusieurs strategies




strategie : estampillage

Transactions estampillees avec lheure de lancement(TimeStamp, TS)

Estampilles des transactions ordre chronologique

die-wound : Une transaction ne peut quattendre quune plusjeune

wound-wait : Une transaction peut attendre seulement uneplus vieille




Autres strategies :

Attente :

no waiting : une transaction est annulee si elle ne peut pasavoir un lock

cautious waiting : une transaction est annulee si elle estbloquee et quune autre transaction est aussi bloquee

timeout : annulation dune transaction qui attend un lockdepuis un temps fixe par le syste`me




recuperation de bases de donnees : reprise

Pannes dun SGBD :

panne dordinateurpanne de disque

Reprise a` chaud : apre`s un abandon de transaction ou unepanne dordinateur, peut etre realisee automatiquement etrapidement, en sappuyant sur la tenue dun journal qui gardeen memoire tous les evenements dune transaction

Reprise a` froid : apre`s une panne de disque est plus longue a`mettre en oeuvre. Elle necessite de realiser des copiesregulie`res de la BD et un archivage des mises a` jour entredeux copies.




Atomicite et durabilite :

Le respect de latomicite peut impliquer de defaire les effetsdune transaction lorsque celle-ci a ete abandonnee

Le respect de la durabilite implique que le SGBD doit etrecapable de remettre la base de donnees en etat apre`s unepanne :

les mises a` jour faites par une transaction non confirmee avantla panne doivent etre defaites

Cest le gestionnaire de reprise qui assure cette tache




Journalisation : (ou logging)

Journal : fichier sequentiel qui contient une suitedenregistrements dont chacun decrit un evenementconcernant la vie des transactions et les modifications de laBD

Fichier sequentiel enregistre sur une memoire stable, c.-a`-d.une memoire qui theoriquement ne peut pas etre detruite

Si necessaire, le journal est sauvegarde regulie`rement sur undisque miroir, bandes magnetiques,




exemple de journalisation

Eve`nement Significatio

( T start) La transaction T a commence

(T D a n) La transaction T a mis a` jour ladonnee Dsavaleur est passee de a a` n

(T commit) La transaction T a ete confirme

(check point) point de reprise




extrait de journal

T1 T2 Journal

start (T1 start)

lock X A

read A(A= 15)

A = A-1

write A (T1 A 15 14)

lock S B

unlock A

start (T2 start)

lock X A

read A

read B

A = A * 2

write A (T2 A 14 28)

commit (T2 commit)

B = B / AOdile PAPINI Bases de donnees



Points de reprise (ou check point)

Point de reprise : marque dans le journal indiquant unmoment ou` :

Aucune transaction netait en coursToutes les donnees ecrites par des transactions anterieures aupoint de reprise avaient ete transferees sur disque

Pour obtenir un point de reprise, il faut donc :

Interdire le debut de nouvelles transactionsLaisser se terminer les transactions en cours


IntroductionDclencheursTransactions

cours bd 5bis

Documents

mysql5odile papini bases

u papini bases

utilisateursodile papini

levenementodile papini

donneesodile papini

antoineodile papini

jourodile papini bases

support de cours