UNION INTERCEPT SELECT WHERE JOINT FROM ACID

Dimension: px
Commencer à balayer dès la page:

Download "UNION INTERCEPT SELECT WHERE JOINT FROM ACID"

Transcription

1 STOCKAGE TRANSACTION, SÉRIALISABILITÉ, NIVEAUX D'ISOLATION 1

2 BASE RELATIONNELLE Un serveur de données relationnel : Rend compte de la «réalité» sous forme de table Met en relation la perception logique et l implémentation physique de la modélisation (d où le qualificatif de Relationnel) Rien n est particularisé (pas de pointeurs à câbler) L ordre est sans importance pour stocker des données Répond aux spécifications de l Algèbre Relationnelle élaborée par l anglais Edgar Codd Opérateurs UNION, INTERCEPT, projection (SELECT), restriction (WHERE), produit cartésien (JOINT), prédicats complexes,.. Implémente un langage structuré de requête SQL avec des schémas, clause FROM, possibilité de structurer les requêtes (les sous requêtes), effectuer des jointures et des produits cartésiens, etc. Implémentation des propriétés d acidité (ACID)

3 POURQUOI UNE TRANSACTION Lier ensemble des opérations qui, logiquement sont indissociables et dont les effets ne peuvent être envisagées séparément. Considérons un exemple d application bancaire 3

4 EXEMPLE Lire compte courant de Mr X Retrancher 1000 DT Écrire résultat dans compte courant Lire compte professionnel de Mr X Ajouter 1000 DT Écrire résultat dans compte professionnel 4

5 EXEMPLE SUITE Lire compte courant de Mr X Retrancher 1000 DT Écrire résultat dans compte courant Panne Lire compte professionnel de Mr X Ajouter 1000 DT Écrire résultat dans compte professionnel 5

6 EXEMPLE SUITE Debut-transaction Lire compte courant de Mr X Retrancher 1000 DT Écrire résultat dans compte courant Lire compte professionnel de Mr X Ajouter 1000 DT Panne Reprise du système jusqu au début de la transaction Écrire résultat dans compte professionnel Fin-Transaction 6

7 C EST QUOI UNE TRANSACTION Une Transaction, une séquence atomique d actions sur une BD (lectures/écritures) séparant un commit ou un rollback du commit ou du rollback suivant. Chaque transaction doit laisser la BD dans un état cohérent après l avoir prise dans un état cohérent. Les utilisateurs peuvent spécifier des contraintes d intégrité simples sur les données et le SGBD se charge de les garder inviolables. En dehors de ça, le SGBD n a pas conscience de la sémantique des données (ex., il ne comprend pas comment les intérêts d un compte bancaire sont calculés). Le fait qu une transaction préserve la cohérence de la BD est au bout du compte de la responsabilité de l utilisateur! 7

8 LES MENACES Problèmes de concurrence pertes d opérations introduction d incohérences verrous mortels (deadlock) Panne de transaction erreur en cours d'exécution du programme applicatif nécessité de défaire les mises à jour effectuées Panne système reprise avec perte de la mémoire centrale toutes les transactions en cours doivent être défaites Panne disque perte de données de la base 8

9 GESTION DES TRANSACTIONS ET L ACIDITÉ Les transactions d une base de données relationnelle sont gouvernées par le principe d acidité. L acidité est une exigence de la norme SQL. Un standard n est pas une norme Concerne les serveurs d applications (J2EE, SAP,..) Elle permet, à la façon d une théorie, de rendre compte fidèlement de ce que l on observe et de pouvoir effectuer des «prédictions» relatives à l intégrité et la cohérence des données. En particulier, elle exige qu il n y ait aucune interférence entre les transactions. ACID Atomicité Consistance Isolation Durabilité

10 DÉFINITION DES PROPRIÉTÉS ACID Atomicité Les modifications sont préservées en totalité ou complètement annulées (COMMIT, ROLLBACK ou points d'arrêt appelés SAVEPOINT) Consistance La Base passe d'un état cohérent à un état cohérent. Isolation Si une autre transaction s'effectue en concurrence, elle semble s'être déroulée avant ou après (un peu comme si l'on était seul à travailler sur la base) Il existe plusieurs niveaux d'isolation Durabilité (Persistance) Les modifications d'état sont permanentes. Elles sont conservées en cas d'incident (CRASH RECOVERY et MEDIA RECOVERY).

11 INTERACTIONS ENTRE LES COMPOSANTS CONSTITUTIFS DU SERVEUR DE DONNÉES ORACLE10G Parameter SPFILE Passord File Databas e Shared Pool Library Cache Data Dictionary cache Instance Oracle10g Database buffer Cache Java Pool Streams SGA SID Redo Log buffer Large Pool PMON SMON DBW0 LGWR CKPT ARCH SYSAUX SYSTEM TEMP UNDO DATAFILE Control file REDO multiplexés Optionnels Archive Mode LOG

12 MULTI VERSIONS ET MULTI UTILISATEURS En concurrence d accès à la base: Une lecture ne doit pas empêcher une écriture Une lecture ne doit pas empêcher une lecture Une écriture ne doit pas empêcher une lecture Une écriture ne doit pas empêcher une écriture Une écriture bloque une écriture qui porte sur la sur la même ligne Dans ce cas, la base est réputée OLTP On Line Transactional Processing (Haut débit transactionnel)

13 COMMIT ET ABORT INTRODUCTION D ACTIONS ATOMIQUES Commit (fin avec succès) et Abort (fin avec échec) Ces actions s'effectuent en fin de transaction COMMIT Validation de la transaction Rend effectives toutes les mises à jour de la transaction ABORT (Rollback) Annulation de la transaction Défait toutes les mises à jour de la transaction 13

14 PRIMITIVES DE GESTION DE TRANSACTIONS BEGIN, COMMIT, ROLLBACK BEGIN TRANSACTION UPDATE Compte1 Val = Val -100 IF SQLCODE <> 0 ROLLBACK ; EXIT ; UPDATE Compte2 Val = Val Provoque l'annulation des mises à jour - Relâche les verrous IF SQLCODE <> 0 ROLLBACK ; EXIT; COMMIT - Reprend la transaction - Provoque l'intégration réelle des mises à jour dans la base - Relâche les verrous

15 EFFET LOGIQUE Update Update Mémoire de la transaction Commit Abort Bases de données Poubelle 15

16 IMPLÉMENTATION DE TRANSACTIONS TID : Identificateur de transaction Inscription dans la BD seulement après le COMMIT Journalisation: Toute opération d'une transaction est notée avant et après l'exécution dans un fichier journal présumé à l'abris de pannes Les opérations de commitement sont notées avant d'être exécutées sur la BD (write- ahead log protocol) Points de reprise (checkpoints) sauvegardes de l'état de la BD et notamment de TIDs de transactions en cours à intervalles réguliers

17 ET SI LA CASSE ARRIVE... On ferme l'accès à la base On reprend le dernier checkpoint On retrouve sur le journal toutes les transactions commises après commencées avant ou après le checkpoint On reexécute chronologiquement ces transactions et seulement ces transactions On rouvre la base aux usagers

18 TRANSACTIONS NON-ACID Transactions imbriquées Transactions longues Transactions distribuées exigent un commitement à 2 phases (2 PC)

19 JOURNAUX ET SAUVEGARDE Journal des images avant Journal contenant les débuts de transactions, les valeurs d'enregistrement avant mises à jour, les fins de transactions (commit ou abort) Il permet de défaire les mises à jour effectuées par une transaction Journal des images après Journal contenant les débuts de transactions, les valeurs d'enregistrement après mises à jour, les fins de transactions (commit ou abort) Il permet de refaire les mises à jour effectuées par une transaction 19

20 JOURNAL DES IMAGES AVANT Utilisé pour défaire les mises à jour : Undo 2.Log Page lue Page modifiée 3.Update 1.Read 4.Write Base de données 20

21 JOURNAL DES IMAGES APRÈS Utilisé pour refaire les mises à jour : Redo 3.Log Page lue Page modifiée 2.Update 1.Read 4.Write Base de données 21

22 GESTION DU JOURNAL Journal avant et après sont unifiés Écrits dans un tampon en mémoire et vider sur disque en début de commit Structure d'un enregistrement : N transaction (Trid) Type enregistrement : {début, update, insert, commit, abort} TupleId (Attribut modifié, Ancienne valeur, Nouvelle valeur)... Problème de taille on tourne sur N fichiers de taille fixe possibilité d'utiliser un fichier haché sur Trid/Tid 22

23 SCÉNARIOS DE REPRISE Les mises à jour peuvent être effectuées directement dans la base (en place) la base est mise à jour immédiatement, ou au moins dès que possible pendant que la transaction est active Les mises à jour peuvent être effectuées en mémoire et installées dans la base à la validation (commit) le journal est écrit avant d'écrire les mises à jour 23

24 STRATÉGIE DO-UNDO Mises à jour en place l'objet est modifié dans la base Utilisation des images avant copie de l'objet avant mise à jour utilisée pour défaire en cas de panne Update Mémoire cache 1. LirePage 2. LogPage 3. WritePage Journal avant Undo Base 24

25 STRATÉGIE DO-REDO Mises à jour en différentiel l'objet est modifié en page différentielle (non en place=ombre) Utilisation des images après copie de l'objet en journal après mise à jour (do) utilisée pour refaire en cas de panne (redo) Update Mémoire cache 1. LirePage 3. LogPage 2. WritePage Journal après Redo Base Ombre Commit 25

26 LA GESTION DES BUFFERS Bufferisation des journaux on écrit le journal lorsqu'un buffer est plein ou lorsqu'une transaction commet Bufferisation des bases on modifie la page en mémoire le vidage sur disque s'effectue en différé (processus E/S) Synchronisation journaux / base le journal doit toujours être écrit avant modification de la base! 26

27 REPRISE À FROID En cas de perte d'une partie de la base, on repart de la dernière sauvegarde Le système retrouve le checkpoint associé Il ré-applique toutes les transactions commises depuis ce point (for each committed Ti : redo (Ti)) 27

28 PROBLÈMES DE CONCURRENCE Objectifs de la concurrence: Permettre l exécution simultanée d un grand nombre de transactions Régler les conflits lecture / écriture Garder de très bonnes performances Éviter les blocages 28

29 PROBLÈME DE CONCURRENCE Nécessité d'exécuter les programmes et requêtes de façon concurrente Garantir que l exécution simultanée de plusieurs programmes se fait correctement Cohérence de la base de données Exécution correcte des programmes Exemples de contextes hautement concurrentiels: annuaires téléphoniques (accès en lecture) systèmes de réservation de billets (lecture et mise à jour) 29

30 CONTRÔLE DE CONCURRENCE Phénomènes indésirables : Lecture sale : Une transaction lit des données écrites par une transaction Lecture non reproductible : Une transaction lit de nouveau des données qu il a lues précédemment et trouve que les données ont été modifiées par une autre transaction (qui a validé depuis la lecture initiale) Lecture fantôme : Une transaction ré-exécute une requête renvoyant un ensemble de lignes satisfaisant une condition de recherche et trouve que l ensemble des lignes satisfaisant la condition a changé à cause 30 d une transaction récemment validée.

31 INFÉRENCES ENTRE ÉCRIVAINS PERTE D OPÉRATION (LOST UPDATE) 1ere transaction Temps 2eme transaction READ D X=D+1 WRITE D=X READ D Y=D*2 WRITE D=Y La mise à jour faite par la 1ère transaction est perdue. 31

32 ECRITURE INCONSISTANTE (ANG. DIRTY WRITE) 1ere transaction Temps 2eme transaction READ C C=C+100 WRITE C ROLLBACK READ C IF C>500 THEN D=D+500 WRITE D Initialement, C le crédit d un compte est < 500. Une 1ère transaction modifie le crédit C d'un compte. Une 2ème lit C dans ce nouvel état, puis, constatant que la provision est suffisante, modifie le débit D du compte. Après annulation de la 1ére transaction, la contrainte d'intégrité D C n est plus vérifiée. 32

33 ENTRE LECTEURS ET ÉCRIVAINS LECTURE INCONSISTANTE (ANG. DIRTY READ) 1ere transaction Temps 2eme transaction READ A A=A-100 WRITE A READ B B=B+100 WRITE B COMMIT READ A READB La 1ère transaction a pour but de faire un virement entre deux comptes A et B, qui satisfait la contrainte d'intégrité "somme A+B invariante". La deuxième transaction lit A et B juste après que la 1ére transaction ait déduit 1000 de A. Elle trouve A+B diminué. 33

34 ENTRE LECTEURS ET ÉCRIVAINS LECTURE NON REPRODUCTIBLE (ANG. NON- REPEATABLE READ) ) 1ere transaction READ P READ P READ P Temps 2eme transaction READ P P=P-2 WRITE P COMMIT Une 1ère transaction consulte les places libres dans un avion et laisse un temps de réflexion à l'utilisateur. Entre temps, une 2ème transaction, qui voit les mêmes places libres, valide deux réservations. La 1ère demande à nouveau les places libres: la liste est diminuée alors qu'elle n'a pas encore choisi ses réservations! 34

35 ENTRE LECTEURS ET ÉCRIVAINS LECTURE FANTÔME (ANG. PHANTOM READ)) 1ere transaction READ P READ P READ P Temps 2eme transaction READ P P=P+1 WRITE P ROLLBACK Cas identique au précédant mais avec libération au lieu de réservation de place par la 2ème transaction. Il n'y a pas alors de conflit à proprement parler mais seulement interrogation sur la validité de ces "apparitions fantômes". 35

36 TERMINOLOGIE ET NOTATION Ti: une transaction de numéro i. Ri: une opération de lecture (read) de Ti. Wi: une opération d écriture (write) de Ti. Ri(x): une opération de lecture sur l objet x, x étant un objet manipulé par Ti (p.e.: ligne, colonne, ). Wi(x): une opération d écriture sur l objet x. Exple: Transaction 1 Transaction 2 R1(x) R2(x) x = x +5 R2(y) W1(x) R2(z) R1(y) x = x + y + z z = x + y W2(x) W1(z) 36

37 TERMINOLOGIE Ordonnancement ( schedule) T1 = R1(x), W1(x), R1(y), W1(Z) T2 = R2(x), R2(y), R2(z), W2(x) S={R1(x), W1(x), R1(y), W1(Z), R2(x), R2(y), R2(z), W2(x)} S est un ordonnancement en série (sériel, serial); toutes les opérations de T1 précèdent celles de T2 (+) Aucun conflit entre les transactions. (-) problème de performance Les mécanismes de contrôle de concurrence tentent d interfolier ( interleave) les opérations de lecture et d écriture de plusieurs transactions; de manière à toujours assurer un résultat identique à un ordonnancement en série. 37

38 PROPRIÉTÉS D EXÉCUTION Recouvrabilité : Possibilité d annuler l effet d une transaction qui abandonne (abort). Solution : Ordre des Commit effectués par les transactions suit l ordre de dépendances Lecture(X)/Ecriture(X). Exemple Conséquence sur l exemple : le nombre de places disponibles a été diminué par T1 et repris par T2, avant que T1 n annule ses réservations. Le nombre de sièges réservé sera plus grand que le nombre effectif de clients ayant validé leur réservation 38

39 PROPRIÉTÉS D EXÉCUTION Sans Abandons en Cascade (Cascadeless) : la lecture d une valeur écrite par une transaction T ne peut se faire qu une fois T a réalisé son Commit. Cascadeless ----> Recouvrable exemple Ici, le rollback de T1 intervient sans que T2 n ait validé. Il faut alors impérativement que le système effectue également un rollback de T2 pour assurer la cohérence de la base : on parle d annulations en cascade (noter qu il peut y avoir plusieurs transactions à annuler).. Solution :la lecture d une valeur écrite par une transaction T ne peut se faire qu une fois T a réalisé son Commit.39

40 PROPRIÉTÉS D EXÉCUTION Strict : l écriture d une valeur déjà affectée par une autre transaction T ne peut se faire qu une fois T a réalisé son Commit. Exemple Ici il n y a pas de dearty read mais une dearty write. En effet T1 a validé après que T2 ait écrit dans s. Donc la validation de T1 enregistre la mise-à-jour de T2 alors que celle-ci s apprête à annuler ses mises-à-jour par la suite. Au moment où T2 va annuler, le gestionnaire de transaction doit remettre la valeur du tuple connue au début de la transaction : ce qui revient à annuler la mise-à-jour de T1 Solution : Cascadeless + retarder les Write(X) jusqu à ce que les écritures effectuées par d autres transactions sur X soient validées (commit). 40

41 PROPRIÉTÉS En résumé, on distingue trois niveaux de recouvrabilité selon le degré de contrainte imposé au système : 1. Recouvrabilité : on ne doit pas avoir à annuler une transaction déjà validée. 2. Annulation en cascade : un rollback sur une transaction ne doit pas entraîner l annulation d autres transactions. 3. Recouvrabilité stricte : deux transactions ne peuvent pas accéder simultanément en écriture à la même donnée, sous peine de ne pouvoir utiliser la technique de récupération de l image avant 41

42 NOTION D ÉQUIVALENCE Deux opérations sont conflictuelles ssi Elles opèrent sur le même objet, Au moins une des 2 opérations est une écriture, Chacune des opérations à une transaction différente. Exemple d opérations conflictuelles: T1 = R1(x), W1(x), R1(y), W1(Z) T2 = R2(x), R2(y), R2(z), W2(x) (R1(x), W2(x)), (W1(x), R2(x)), (W1(x), W2(x)), (W1(z), R2(z)) Deux exécutions sont équivalentes si: Les mêmes actions (lecture, écriture) se retrouvent dans les mêmes transactions Chaque paire de d actions conflictuelle (lecture/écriture, écriture/lecture ou écriture/écriture) sont ordonnées de la même façon dans les deux exécutions 42

43 EXÉCUTION SÉRIALISABLE Une exécution S est sérialisable si S est équivalente à une exécution en série des mêmes transactions Exemple : Soit le programme réservation de spectacle, représenté par la séquence suivante : r(s) r(c) w(c) w(s) r : Lecture (Read) w : Ecriture (Write) s : Séance c : Client 43

44 Exécution sérialisable Soient deux transactions T1 et T2, chacun voulant réserver des places pour la même séance pour deux clients distincts c1 et c2. Soit la situation suivante : Il reste 50 places libres pour la séance s T1 veut réserver 5 places pour la séance s T2 veut réserver 2 places pour la séance s Soit le déroulement imbriqué de ces deux réservations r1(s) r1(c1) r2(s) r2(c2) w2(s) w2(c2) w1(s) w1(c1) T1 lit s et c1 : places libres 50 T2 lit s et c2 : places libres 50 Pbm!! Il reste 45 places libres T2 écrit s : 50-2 = 48 alors que 7 places ont été T2 écrit le nouveau compte de c2 T1 écrit s : 50-5 = 45 réservées : T2 lit et modifie une information que T1 a déjà T1 écrit le nouveau compte de c1 lue en vue de la modifier 44

45 EXÉCUTION SÉRIALISABLE Solution1 : Exécuter en série les transactions, on bloque une tant que la précédente n a pas fini son exécution. r1(s) r1(c1) w1(s) w1(c1) r2(s) r2(c2) w2(s) w2(c2) Dans ce cas, pas de problèmes. T2 lit une donnée écrite par T1 qui a terminé son exécution et ne créera donc pas d interférences. Cette solution n est pas acceptable, on ne peut pas se permettre de bloquer tous les utilisateurs sauf un, en attente d une transaction qui peut durer très longtemps 45

46 EXÉCUTION SÉRIALISABLE Solution2 : Exécution entremele de T1et T2 r1(s) r1(c1) w1(s) r2(s) r2(c2) w2(s) w1(c1) w2(c2) T1 lit s et c1 : places libres 50 T1 écrit s = 50 5 = 45 T2 lit s : places libres 45 T2 lit c2 T2 écrit s = 45 2 = 43 T1 écrit le nouveau compte de c1 T2 écrit le nouveau compte de c2 Le résultat obtenu est le même obtenu par une exécution en série, on parle alors de sérialisabilité 46

47 SÉRIALISABILITÉ Hypothèses: Exécution d'une transaction individuelle est correcte Exécution de transactions en série (les unes derrière les autres) est correcte Idée: se ramener à une exécution de transactions en série Concept de sérialisabilité 47

48 GRAPHE DE DÉPENDANCES Il est possible de déterminer la sérialisabilité d'une exécution. On met en oeuvre des relations de précédence entre les transactions. Une fois toutes les relations de précédence établies, on peut générer un graphe dit de dépendance (précédence) Théorème: Une exécution est sérialisable ssi son graphe de dépendance ne comporte pas de cycle Graphe dépendances : Un noeud par transaction; liens de Ti à Tj si Tj effectue une lecture/écriture d une granule précédemment écrit par Ti, ou si Tj effectue une écriture d un granule précédemment lu par Ti. 48

49 GRAPHE DE DÉPENDANCES 1. Chaque transaction est un noeud du graphe; 2. Pour un objet O : Si une transaction T1 fait une écriture de l'objet O avant qu'une transaction T2 ne fasse une opération sur cet objet alors, dans le graphe, T1 précède T2 : Cette relation de précédence est concrétisée par un arc orientée de T1 vers T2. 3. Pour un objet O : Si une transaction T1 fait une lecture sur l'objet O avant qu'une transaction T2 ne fasse une opération d'éciture sur cet objet, alors, dans le graphe, T1 précède T2: 4. L'exécution est sérialisable si et seulement si le graphe ne présente aucun cycle. 49

50 GRAPHE DE DÉPENDANCES T1 T2 T3 Lire (X) Ecrire (X) Lire (Y) Ecrire (Y) Lire (Z) Lire (Y) Ecrire (Y) Lire (X) Ecrire (X) Lire (Y) Lire (Z) Ecrire (Y) Ecrire (Z) - Définir pour chaque objet la liste des transactions qui accèdent a l'objet par ordre chronologique. - dresser le graphe pour determiner si c est serialisable ou non 50

51 GRAPHE DE DÉPENDANCES Pour L'objet X: Lecture de T1, Ecriture de T1, Lecture de T2, Ecriture de T2. Relation de précédence: T1 précède T2. Pour l'objet Y: Lecture de T2, Ecriture de T2, Lecture de T3, Ecriture de T3, Lecture de T1, Ecriture de T1. Relation de précédence: T2 ecrit avant T3 donc T2 précède T3; T3 ecrit avant T1 donc T3 précède T1. Pour l'objet Z: Lecture de T2, Lecture de T3, Ecriture de T3. Relation de précédence: Le fait que T2 lise avant que T3 ne lise ne provoque pas de conflit. Cependant, la précédence doit être exprimée ici, parce que T3 fait par la suite une opération d'écriture sur Z. 51

52 GRAPHE DE DÉPENDANCES Toutes les transactions sont représentées par des noeuds. On indique que T1 précède T2 en dessinant une flèche de T1 vers T2. Pour plus de clarté, on peut mettre sous chaque flèche, l'objet a partir duquel a été déduite la relation représentée par la flèche. Le graphe de précédence ressemble alors a ce qui suit: X T1 T2 L exécution donnée n est pas serialisable Y T3 Y,Z 52

53 GRAPHE DE DÉPENDANCES Exemple2 : T1 T2 T3 Lire (X) Ecrire (X) Lire (Y) Ecrire (Y) Lire (Z) Lire (Y) Lire (Z) Ecrire (Y) Ecrire (Z) Lire (Y) Ecrire (Y) Lire (X) Ecrire (X) 53

54 GRAPHE DE DÉPENDANCES Pour L'objet X: Lecture de T1, Ecriture de T1, Lecture de T2, Ecriture de T2. Relations de précédence: On détermine sans difficulté que T1 précède T2. Pour l'objet Y: Lecture de T3, Ecriture de T3, Lecture de T1, Ecriture de T1, Lecture de T2, Ecriture de T2. Relations de précédence: T3 écrit avant T1 donc T3 précède T1; T3 écrit avant T2 donc T3 précède T2; T1 écrit avant T2 donc T1 précède T2. Pour l'objet Z: Lecture de T3, Ecriture de T3, Lecture de T2. Relations de précédence: T3 écrit avant T2 donc T3 précède T2. 54

55 GRAPHE DE DÉPENDANCES T1 X,Y T2 Il n'y a pas de cycle dans ce graphe de sérialisabilite. L execution est serialisable. Y Z T3 55

56 APPROCHE DE LA GESTION DE LA CONCURRENCE Objectif: forcer la sérialisabilité Deux méthodes: Verrouillage Estampillage Verrouillage: L idée est simple : on bloque l accès à une donnée dès qu elle est lue ou écrite par une transaction («pose de verrou») et on libère cet accès quand la transaction termine par commit ou rollback («libération du verrou») Le verrou partagé (SLocks) est typiquement utilisé pour permettre à plusieurs transactions concurrentes de lire la même ressource. Le verrou exclusif (XLocks) réserve la ressource en écriture à la transaction qui a posé le verrou. 56

57 VERROUS EXCLUSIF : PROTOCOLE PXO Définition: un verrou est dit exclusif s'il interdit toute autre obtention d'un verrou, de quelque type que ce soit, sur l'élément verrouillé, par une autre transaction. Verrous exclusifs avec libération explicite Toute demande d accès contient implicitement une demande de verrouillage (Lire XLire). Toute transaction qui a besoin d une ressource qui est actuellement verrouillée est mise en attente (FIFO). L'obtention du verrou autorise lectures et mises à jour Un verrou peut être relâché explicitement (XRelâcher) à n importe quel moment. Au plus tard, il est relâché implicitement à la fin de la transaction. 57

58 VERROUILLAGE EXCLUSIF: EXEMPLE ET PROBLÈMES 58

59 SOLUTIONS DES INTERBLOCAGES Deux approches: Détection: laisser les transactions se mettre en interblocage, le détecter puis le résoudre. Grâce au graphe de dépendances : un interblocage: un cycle dans le graphe Quand faire la détection? lors des demandes de verrouillage périodiquement après un certain temps d attente pour une transaction Action: tuer l une des transactions celle qui a fait le moins de maj la plus jeune celle qui a le moins de ressources allouées Tuer: défaire (annuler ses maj, ses verrous) puis relancer automatiquement plus Tard Prévention: prévenir les interblocages. En pratique, solution détection la plus souvent utilisée car prévention plus coûteuse. 59

60 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 60

61 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 61

62 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 62

63 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) 63 Verrou exclusif Verrou partagé Verrou ligne RX RS Verrou table X S

64 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 64

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

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

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

68 VERROUILLAGE EXCLUSIF DES LIGNES (RX) Ce mode est acquis de façon automatique pour une table modifiée par l'une des instructions suivantes : 68 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

69 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. X Verrou obtenu par une transaction Verrous impossibles pour les autres transactions RS, RX, S, X Verrous possibles pour les autres transactions 69 S RX, X RS, S RX S, X RX, RS RS X RS, RX, S

70 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 70

71 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 71

72 CONTRÔLE DE CONCURRENCE : PROTOCOLE DE S2PL Sans verrou T1 R(A) W(A) R(B) W(B) Commit T2 R(A) W(A) R(B) W(B) Commit Protocole S2PL T1 T2 X(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 72

73 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 73

74 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 74

Bases de données et sites WEB Licence d informatique LI345

Bases de données et sites WEB Licence d informatique LI345 Bases de données et sites WEB Licence d informatique LI345 Anne Doucet Anne.Doucet@lip6.fr http://www-bd.lip6.fr/ens/li345-2013/index.php/lescours 1 Contenu Transactions en pratique Modèle relationnel-objet

Plus en détail

Les transactions 1/40. I même en cas de panne logicielle ou matérielle. I Concept de transaction. I Gestion de la concurrence : les solutions

Les transactions 1/40. I même en cas de panne logicielle ou matérielle. I Concept de transaction. I Gestion de la concurrence : les solutions 1/40 2/40 Pourquoi? Anne-Cécile Caron Master MAGE - BDA 1er trimestre 2013-2014 Le concept de transaction va permettre de définir des processus garantissant que l état de la base est toujours cohérent

Plus en détail

12. Concurrence et transactions. OlivierCuré [ocure@univ-mlv.fr]

12. Concurrence et transactions. OlivierCuré [ocure@univ-mlv.fr] 12. Concurrence et transactions 354 Plan Notion de transaction Théorie de la concurrence Sérialisation Techniques pessimistes et optimistes Gestion de transactions Validation Reprise après panne 355 12.1

Plus en détail

Concurrence. Concurrence d accès. Nicolas Travers nicolas.travers@cnam.fr

Concurrence. Concurrence d accès. Nicolas Travers nicolas.travers@cnam.fr Concurrence Concurrence d accès FIP1 - Bases de Données Nicolas Travers nicolas.travers@cnam.fr Équipe Vertigo Laboratoire CEDRIC Conservatoire National des Arts & Métiers, Paris, France 1 / 36 Plan Concurrence

Plus en détail

Cours Bases de données 2ème année IUT

Cours Bases de données 2ème année IUT Cours Bases de données 2ème année IUT Cours 12 : Concurrence d accès Anne Vilnat http://www.limsi.fr/individu/anne/cours Plan 1 Accès concurrents Définitions Verrous Collisions Niveaux de cohérence Blocage

Plus en détail

Les transactions 1/46. I même en cas de panne logicielle ou matérielle. I Concept de transaction. I Gestion de la concurrence : les solutions

Les transactions 1/46. I même en cas de panne logicielle ou matérielle. I Concept de transaction. I Gestion de la concurrence : les solutions 1/46 2/46 Pourquoi? Anne-Cécile Caron Master MAGE - SGBD 1er trimestre 2014-2015 Le concept de transaction va permettre de définir des processus garantissant que l état de la base est toujours cohérent

Plus en détail

Pierre Parrend IUT Lumière Lyon II, 2005-2006 pierre.parrend@univ-lyon2.fr. Bases de Données Avancées - Transactions

Pierre Parrend IUT Lumière Lyon II, 2005-2006 pierre.parrend@univ-lyon2.fr. Bases de Données Avancées - Transactions Pierre Parrend IUT Lumière Lyon II, 2005-2006 pierre.parrend@univ-lyon2.fr Bases de Données Avancées - Transactions Sommaire I. Introduction II. Transactions et SQL III. Contrôle de la Concurrence IV.

Plus en détail

Programme accédant et/ou modifiant des données persistantes (fichier ou BD) avec propriétés :

Programme accédant et/ou modifiant des données persistantes (fichier ou BD) avec propriétés : Transaction réservation(date, nbplace) select reste into r from RESERVATION where dateresa=:date si (r >= nbplace) alors update RESERVATION set reste=reste-nbplace where dateresa=:date éditer-place(date,

Plus en détail

Transactions et concurrence

Transactions et concurrence Transactions et concurrence Le concept de transaction Les états d une transaction Exécutions concurrentes Sérialisabilité Définition des transactions dans SQL Test de sérialisabilité Le concept de transaction

Plus en détail

Cours Bases de données

Cours Bases de données Cours Bases de données Concurrence d accès 3 année (MISI) Antoine Cornuéjols www.lri.fr/~antoine antoine.cornuejols@agroparistech.fr Contrôle de la concurrence d accès 1. Introduction 1.1. Systèmes multi-utilisateurs

Plus en détail

Implémentation des SGBD

Implémentation des SGBD Implémentation des SGBD Structure générale des applications Application utilisateur accédant à des données d'une base Les programmes sous-jacents contiennent du code SQL Exécution : pendant l'exécution

Plus en détail

Module BDR Master d Informatique

Module BDR Master d Informatique Module BDR Master d Informatique Cours 8- Reprise sur pannes Anne Doucet Anne.Doucet@lip6.fr 1 Gestion de transactions Définition Exemples Propriétés des transactions Fiabilité et tolérance aux pannes

Plus en détail

SURETE DE FONCTIONNEMENT ET REPRISE APRES PANNE

SURETE DE FONCTIONNEMENT ET REPRISE APRES PANNE Université des sciences et de la Technologie Houari Boumediene USTHB Alger Département d Informatique ARCHITECTURE ET ADMINISTRATION DES BASES DE DONNÉES 2013-2014 RESPONSABLES M. KAMEL BOUKHALFA (SII)

Plus en détail

COMPOSANTS DE L ARCHITECTURE D UN SGBD. Chapitre 1

COMPOSANTS DE L ARCHITECTURE D UN SGBD. Chapitre 1 1 COMPOSANTS DE L ARCHITECTURE D UN SGBD Chapitre 1 Généralité 2 Les composants principaux de l architecture d un SGBD Sont: Les processus Les structures mémoires Les fichiers P1 P2 Pn SGA Fichiers Oracle

Plus en détail

Gestion des transactions et accès concurrents dans les bases de données relationnelles

Gestion des transactions et accès concurrents dans les bases de données relationnelles Gestion des transactions et accès concurrents dans les bases de données relationnelles Bernard ESPINASSE Professeur à Aix-Marseille Université (AMU) Ecole Polytechnique Universitaire de Marseille Fev.

Plus en détail

Gestion des Journaux. Méthodes d accès aux données. Système d exploitation. Gestion de Verrous. Gestion de. Mémoire. Gestion de transactions Page 2

Gestion des Journaux. Méthodes d accès aux données. Système d exploitation. Gestion de Verrous. Gestion de. Mémoire. Gestion de transactions Page 2 Gestion de Transactions Propriétés ACID d'une transaction Protocoles de contrôle de concurrence Protocoles de résistance aux pannes Gestion de transactions Page 1 Définition d une transaction Transaction

Plus en détail

Administration des bases de données

Administration des bases de données Administration des bases de données Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine/ Administration des bases de données IV SGBD Transactionnels : protection et sécurité des données OBJECTIFS

Plus en détail

Bases de données temps-réel www.enst.fr/~talel/cours/tram/rtdbms.pdf

Bases de données temps-réel www.enst.fr/~talel/cours/tram/rtdbms.pdf Bases de données temps-réel www.enst.fr/~talel/cours/tram/rtdbms.pdf Talel.Abdessalem@enst.fr Plan Applications temps réel et SGBD Les SGB traditionnels Modèles et approches pour le temps réel Produits

Plus en détail

Bases de données avancées Concurrence d'accès et reprise

Bases de données avancées Concurrence d'accès et reprise Bases de données avancées Concurrence d'accès et reprise Dan VODISLAV Université de Cergy-Pontoise Master Informatique M1 Cours BDA Plan La notion de transaction Les problèmes de la concurrence Problèmes

Plus en détail

Quel SGBDR pour VFP?

Quel SGBDR pour VFP? D. Peralta le 4 mars 2008 Rencontres AtoutFox 2007/2008 Quel SGBDR pour VFP? Lors des précédentes rencontres, nous avons écrit des articles sur l utilisation des SGBDR avec VFP. Nous avons vu les différentes

Plus en détail

Plan de cette partie. Implantation des SGBD relationnels. Définition et fonctionnalités. Index. Coûts pour retrouver des données

Plan de cette partie. Implantation des SGBD relationnels. Définition et fonctionnalités. Index. Coûts pour retrouver des données Implantation des SGBD relationnels Université de Nice Sophia-Antipolis Version 3.4 25//06 Richard Grin Plan de cette partie Nous allons étudier (très rapidement!) quelques éléments de solutions utilisés

Plus en détail

Définition: Transaction

Définition: Transaction Concurrence des accès Atomicité à la concurrence Concurrency atomicity Concepts 2PL Définition: Transaction Une transaction est une unité de travail Un ensemble d actions qui prend la base de données dans

Plus en détail

Données Réparties. Thibault BERNARD. thibault.bernard@univ-reims.fr

Données Réparties. Thibault BERNARD. thibault.bernard@univ-reims.fr Données Réparties Thibault BERNARD thibault.bernard@univ-reims.fr Sommaire Introduction Gestion de la concurrence Reprise après panne Gestion des données dupliquées Sommaire Introduction Gestion de la

Plus en détail

SGBDR. Systèmes de Gestion de Bases de Données (Relationnelles)

SGBDR. Systèmes de Gestion de Bases de Données (Relationnelles) SGBDR Systèmes de Gestion de Bases de Données (Relationnelles) Plan Approches Les tâches du SGBD Les transactions Approche 1 Systèmes traditionnels basés sur des fichiers Application 1 Gestion clients

Plus en détail

Les journées SQL Server 2013

Les journées SQL Server 2013 Les journées SQL Server 2013 Un événement organisé par GUSS Les journées SQL Server 2013 Les Verrous Arian Papillon, MVP SQL Server Frédéric Brouard, MVP SQL Server Un événement organisé par GUSS Arian

Plus en détail

Cours Administration BD

Cours Administration BD Faculté des Sciences de Gabès Cours Administration BD Chapitre 2 : Architecture Oracle Faîçal Felhi felhi_fayssal@yahoo.fr 1 Processus serveur 1 Mémoire PGA Architecture SGBD Oracle Processus serveur 2

Plus en détail

Transcations réparties. Concept de transaction. Exemple de transaction. Propriétés des transactions (ACIDité) Page 1

Transcations réparties. Concept de transaction. Exemple de transaction. Propriétés des transactions (ACIDité) Page 1 Transcations réparties Concept de transaction Gestion de transactions Transactions dans un système réparti Une transaction est une collection d'actions qui transforment la BD (ou des fichiers) depuis un

Plus en détail

Cours de Base de Données Cours n.12

Cours de Base de Données Cours n.12 Cours de Base de Données Cours n.12 Gestion des transactions : contrôle de concurrence Elisabetta De Maria - http://www.i3s.unice.fr/ edemaria/ UFR Sciences et Laboratoire I3S, CNRS 2013-2014 Université

Plus en détail

Niveau d isolation et anomalies transactionnelles.

Niveau d isolation et anomalies transactionnelles. Niveau d isolation et anomalies transactionnelles. Peu connu et souvent mal utilisés, les niveaux d'isolation des transactions permettent de rendre plus ou moins étanches (ou poreuses) les transactions

Plus en détail

4.1 Principe. Techniques SQL avancées. 1. Rappel des notions de base de données 2. Intégrité des données 3. Transactions

4.1 Principe. Techniques SQL avancées. 1. Rappel des notions de base de données 2. Intégrité des données 3. Transactions Techniques SQL avancées 4.1 Principe 1. Rappel des notions de base de données 2. Intégrité des données 3. Transactions 4.1 Principes 4.3 Sauvegarde (backup) 4.4 Journal (log) 4.5 Reprise suite à un incident

Plus en détail

Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des fins de citation.

Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des fins de citation. 1 Les Transactions Une transaction est une séquence d opérations sur un serveur. 1.1 Le concept Le principe s'inspire des transactions tout ou rien de l'époque primitive des bandes magnétiques sans l'utilisation

Plus en détail

SGBD : Bases de données avancées [M3106C]

SGBD : Bases de données avancées [M3106C] SGBD : Bases de données avancées [M3106C] Hocine ABIR 10 septembre 2014 IUT Villetaneuse E-mail: abir@iutv.univ-paris13.fr TABLE DES MATIÈRES 4 Gestion des Accès Concurrents sous PostgreSQL 1 4.1 Introduction...............................

Plus en détail

Notion de base de données

Notion de base de données Notion de base de données Collection de données opérationnelles enregistrées sur un support adressable et utilisées par les systèmes et les applications Les données doivent être structurées indépendamment

Plus en détail

3. La SGA ou System global Area

3. La SGA ou System global Area 1/11 L'instance Oracle Oracle est une base de données composée de 3 parties différentes : L'instance Les fichiers de données Les fichiers de données facultatifs (fichier d'initialisation, fichier de mots

Plus en détail

//////////////////////////////////////////////////////////////////// Administration bases de données

//////////////////////////////////////////////////////////////////// Administration bases de données ////////////////////// Administration bases de données / INTRODUCTION Système d informations Un système d'information (SI) est un ensemble organisé de ressources (matériels, logiciels, personnel, données

Plus en détail

Systèmes de gestion de bases de données

Systèmes de gestion de bases de données Systèmes de gestion de bases de données Introduction a la notion de transaction P. Rigaux Cnam, dépt. informatique May 20, 2015 PR (Cnam, dépt. info) Systèmes de gestion de bases de données May 20, 2015

Plus en détail

Rappel sur les Transactions

Rappel sur les Transactions Rappel sur les Transactions Didier DONSEZ Université Joseph Fourier (Grenoble 1) IMAG/LSR/ADELE Didier.Donsez@imag.fr Agenda Notion de Transaction Propriétés ACID Contrôle de concurrence Reprise sur Panne

Plus en détail

Architecture serveur de pages (2) Bilan architecture serveur de pages. Architecture multi-serveur. Pertes de mise à jour

Architecture serveur de pages (2) Bilan architecture serveur de pages. Architecture multi-serveur. Pertes de mise à jour Introduction Chapitre 5. Implémentation des SGBDO 1 architectures client/serveur 2 concurrence, pannes 3 Quelques SGBDRO 4 Quelques SGBDOO années 80 : serveur : BD client : applications et langages appel

Plus en détail

Administration des bases de données relationnelles Part I

Administration des bases de données relationnelles Part I Administration des bases de données relationnelles Part I L administration des bases de données requiert une bonne connaissance - de l organisation et du fonctionnement interne du SGBDR : structures logiques

Plus en détail

Réplication des données

Réplication des données Réplication des données Christelle Pierkot FMIN 306 : Gestion de données distribuées Année 2009-2010 Echange d information distribuée Grâce à un serveur central Une seule copie cohérente Accès à distance

Plus en détail

CHAPITRE 1 ARCHITECTURE

CHAPITRE 1 ARCHITECTURE 07/04/2014 Université des sciences et de la Technologie Houari Boumediene USTHB Alger Département d Informatique ADMINISTRATION ET TUNING DE BASES DE DONNÉES CHAPITRE 1 ARCHITECTURE RESPONSABLE DR K. BOUKHALFA

Plus en détail

Bases de données. Cours 6 : Introduction à des notions avancées (Index, Déclencheurs, Transactions) Nicolas DURAND

Bases de données. Cours 6 : Introduction à des notions avancées (Index, Déclencheurs, Transactions) Nicolas DURAND Bases de données Cours 6 : Introduction à des notions avancées (Index, Déclencheurs, Transactions) Nicolas DURAND Polytech Marseille Université d Aix-Marseille 2012-2013 Nicolas DURAND Bases de données

Plus en détail

Module Bases de Données et Sites Web Partiel du 1 er avril 2005

Module Bases de Données et Sites Web Partiel du 1 er avril 2005 Université Pierre et Marie Curie - Paris 6 - UFR 922 - Licence d'informatique Module Bases de Données et Sites Web Partiel du 1 er avril 2005 Documents autorisés Durée : 2h. Exercice 1 : Autorisation Question

Plus en détail

Bases de données cours 1

Bases de données cours 1 Bases de données cours 1 Introduction Catalin Dima Objectifs du cours Modèle relationnel et logique des bases de données. Langage SQL. Conception de bases de données. SQL et PHP. Cours essentiel pour votre

Plus en détail

10/04/2011. Serveur de données. Serveur de données. Client. Programme d'application Logiciel intermédiaire Pilote de télécommunication.

10/04/2011. Serveur de données. Serveur de données. Client. Programme d'application Logiciel intermédiaire Pilote de télécommunication. 1 BD locale BD locale Programme d'application Logiciel intermédiaire Client SGBD réparti Logiciel intermédiaire données SGBD réparti Logiciel intermédiaire données 2 Bénéfices potentiels Performance Fiabilité

Plus en détail

Module BDR Master d Informatique (SAR)

Module BDR Master d Informatique (SAR) Module BDR Master d Informatique (SAR) Cours 9- Transactions réparties Anne Doucet Anne.Doucet@lip6.fr Transactions réparties Gestion de transactions Transactions dans un système réparti Protocoles de

Plus en détail

CHAPITRE 1 ARCHITECTURE BASES DE DONNÉES AVANCÉES 2014-2015 20/10/2014. Université des sciences et de la Technologie Houari Boumediene USTHB Alger

CHAPITRE 1 ARCHITECTURE BASES DE DONNÉES AVANCÉES 2014-2015 20/10/2014. Université des sciences et de la Technologie Houari Boumediene USTHB Alger Université des sciences et de la Technologie Houari Boumediene USTHB Alger Département d Informatique BASES DE DONNÉES AVANCÉES 2014-2015 RESPONSABLES M. KAMEL BOUKHALFA (SII CHAPITRE 1 ARCHITECTURE 1

Plus en détail

Multi-processeurs, multi-cœurs et cohérence mémoire et cache

Multi-processeurs, multi-cœurs et cohérence mémoire et cache Multi-processeurs, multi-cœurs et cohérence mémoire et cache Intervenant : Thomas Robert Institut Mines-Télécom Rappel système d exploitation & Parallélisme L unité d exécution pour un système d exploitation

Plus en détail

Data Base Buffer Cache :

Data Base Buffer Cache : Suite cours SG chapitre 2 Data Base Buffer Cache : Il stocke les bloques de données les plus recement utilisées lorsque Oracle doit executer une requete SQL, il verifie tout d'abort si la requete existe

Plus en détail

Cours Bases de données

Cours Bases de données Informations sur le cours Cours Bases de données 9 (10) séances de 3h Polycopié (Cours + TD/TP) 3 année (MISI) Antoine Cornuéjols www.lri.fr/~antoine antoine.cornuejols@agroparistech.fr Transparents Disponibles

Plus en détail

Introduction aux SGBDR

Introduction aux SGBDR 1 Introduction aux SGBDR Pour optimiser une base Oracle, il est important d avoir une idée de la manière dont elle fonctionne. La connaissance des éléments sous-jacents à son fonctionnement permet de mieux

Plus en détail

Chapitre 5. Communication interprocessus. 5.1 Introduction

Chapitre 5. Communication interprocessus. 5.1 Introduction Communication interprocessus 5.1 Introduction Dans une activité parallèle (ou pseudo parallèle), un ensemble de processus séquentiels s exécutent en parallèle. Cette exécution résulte deux types de relations

Plus en détail

PLAN DE COURS ORACLE : ADMINISTRATION DE BASES DE DONNEES. Objectif. Code. Dure e. Public Concerne. Pre -requis. Programme OR305

PLAN DE COURS ORACLE : ADMINISTRATION DE BASES DE DONNEES. Objectif. Code. Dure e. Public Concerne. Pre -requis. Programme OR305 PLAN DE COURS ORACLE : ADMINISTRATION DE BASES DE DONNEES Objectif Administrer une ou plusieurs bases de, tant sous l'aspect "gestionnaire de " que sous l'aspect "responsable système Oracle". Public Concerne

Plus en détail

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base)

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) 1. Généralités sur l'information et sur sa Représentation 1.1 Informations et données : a. Au sen de la vie : C

Plus en détail

synchronisation et communication entre processus Synchronisation et communication entre processus

synchronisation et communication entre processus Synchronisation et communication entre processus 1 Synchronisation et communication entre processus Accès à des ressources communes 2 Exemple: compte bancaire dont montant en A sur disque programme pour ajouter 100: lire(n,a) N := N+100 écrire(n,a) 2

Plus en détail

ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES. Cours Administration des Bases de données M Salhi

ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES. Cours Administration des Bases de données M Salhi ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES Cours Administration des Bases de données M Salhi Architectures des Système de base de données Systèmes centralisés et client-serveur Server System Architectures

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

Oracle Database 10g: Les fondamentaux du langage SQL I

Oracle Database 10g: Les fondamentaux du langage SQL I Oracle University Appelez-nous: +33 (0) 1 57 60 20 81 Oracle Database 10g: Les fondamentaux du langage SQL I Durée: 3 Jours Description Ce cours offre aux étudiants une introduction à la technologie de

Plus en détail

TP8 - Gestion Transactionnelle

TP8 - Gestion Transactionnelle TP8 - Gestion Transactionnelle MIAGE #3-2006/2007 November 29, 2006 1 Transactions sous Oracle Il est nécéssaire pour ce T.P. de travailler par binômes connectés simultanement (sous SQL*PLUS) sur deux

Plus en détail

Transaction. 1:débiter(1000) 2:créditer(1000)

Transaction. 1:débiter(1000) 2:créditer(1000) Transaction Il n'est pas rare qu'une opération se divise en plusieurs autres opérations élémentaires sur la base de données. Dans ce cas, l''état de la base de données avant l'opération est maintenue cohérent,

Plus en détail

Chapitre 1. Introduction aux Bases de Données. Cours de Bases de Données. Polytech Paris-Sud. Chapitre 1 : Quelques questions

Chapitre 1. Introduction aux Bases de Données. Cours de Bases de Données. Polytech Paris-Sud. Chapitre 1 : Quelques questions Cours de Bases de Données Chapitre 1 Polytech Paris-Sud Sarah Cohen-Boulakia LRI, Bât 490, Université Paris-Sud 11, Orsay cohen @ lri. fr 01 69 15 32 16 Introduction aux Bases de Données 1 2 Chapitre 1

Plus en détail

Multi-processeurs, multi-cœurs, cohérence mémoire et cache

Multi-processeurs, multi-cœurs, cohérence mémoire et cache Multi-processeurs, multi-cœurs, cohérence mémoire et cache Intervenant : Thomas Robert Institut Mines-Télécom Parallélisme inter instructions n Exécution : une séquence d instructions appliquées à un 1

Plus en détail

Tolérance aux pannes

Tolérance aux pannes Tolérance aux pannes Arnaud Labourel Université de Provence 15 mars 2012 Arnaud Labourel (Université de Provence) Tolérance aux pannes 15 mars 2012 1 / 55 Présentation Tolérances aux pannes Pannes Définition

Plus en détail

Transactionnel et transactionnel réparti. Source R.CHEVANCE G.Gardarin

Transactionnel et transactionnel réparti. Source R.CHEVANCE G.Gardarin 1 Transactionnel et transactionnel réparti Source R.CHEVANCE G.Gardarin Plan Concept de transaction - Propriétés ACID Transactionnel réparti Moniteur transactionnel Modèle X/Open Exemple de moniteur transactionnel:

Plus en détail

Gestion des transactions dans le relationnel Résistance aux pannes et sécurité

Gestion des transactions dans le relationnel Résistance aux pannes et sécurité Gestion des transactions dans le relationnel Résistance aux pannes et sécurité Bernard ESPINASSE Professeur à Aix-Marseille Université (AMU) Ecole Polytechnique Universitaire de Marseille Février 2013

Plus en détail

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/ Systèmes de gestion de bases de données Introduction Université d Evry Val d Essonne, IBISC utiles email : cinzia.digiusto@gmail.com webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

SQL : création et mises-à-jour de schémas et de données

SQL : création et mises-à-jour de schémas et de données SQL : création et mises-à-jour de schémas et de données Commandes de définition de données (DDL) Commandes de mise-à-jour de données (DML) Vues SQL-MAJ, vues-1 / 33 Exemple Définition de la relation

Plus en détail

Plan de formation : Certification OCA Oracle 11g. Les administrateurs de base de données (DBA) Oracle gèrent les systèmes informatiques

Plan de formation : Certification OCA Oracle 11g. Les administrateurs de base de données (DBA) Oracle gèrent les systèmes informatiques Plan de formation : Certification OCA Oracle 11g Description Les administrateurs de base de données (DBA) Oracle gèrent les systèmes informatiques industriels les plus avancés. Cette formation permettra

Plus en détail

Bases de données avancées Introduction

Bases de données avancées Introduction Bases de données avancées Introduction Dan VODISLAV Université de Cergy-Pontoise Master Informatique M1 Cours BDA Plan Objectifs et contenu du cours Rappels BD relationnelles Bibliographie Cours BDA (UCP/M1)

Plus en détail

Il est nécessaire de connaître au moins un système d'exploitation de type graphique.

Il est nécessaire de connaître au moins un système d'exploitation de type graphique. GBD-030 Oracle Prise en main Saint-Denis à 9h30 5 jours Objectifs : Une formation Oracle complète pour découvrir tous les concepts du système et les différentes façons de les utiliser concrètement tout

Plus en détail

2A-SI 4 - Bases de Données 4.2 - Modèle relationnel

2A-SI 4 - Bases de Données 4.2 - Modèle relationnel 2A-SI 4-4.2 - Modèle relationnel Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Avec l aide du cours de Y. Bourda Généralités du «modèle relationnel» : Formalisé par CODD

Plus en détail

Oracle Maximum Availability Architecture

Oracle Maximum Availability Architecture Oracle Maximum Availability Architecture Disponibilité des systèmes d informations Technologies et recommandations 1 Qu est-ce que Oracle Maximum Availability Architecture (MAA)? 1. Objectif : Disponibilité

Plus en détail

Généralités sur les bases de données

Généralités sur les bases de données Généralités sur les bases de données Qu est-ce donc qu une base de données? Que peut-on attendre d un système de gestion de bases de données? Que peut-on faire avec une base de données? 1 Des données?

Plus en détail

Bases de Données Réparties Examen du 15 mai 2007

Bases de Données Réparties Examen du 15 mai 2007 Nom : Prénom : page 1 Université Pierre et Marie Curie - Paris 6 - UFR 922 - Master d'informatique (SAR) Bases de Données Réparties Examen du 15 mai 2007 Elements de correction Les documents ne sont pas

Plus en détail

Présentation du module Base de données spatio-temporelles

Présentation du module Base de données spatio-temporelles Présentation du module Base de données spatio-temporelles S. Lèbre slebre@unistra.fr Université de Strasbourg, département d informatique. Partie 1 : Notion de bases de données (12,5h ) Enjeux et principes

Plus en détail

Langage de Requêtes. talel@infres.enst.fr

Langage de Requêtes. talel@infres.enst.fr Langage de Requêtes talel@infres.enst.fr Supports de cours : (1) Database Management Systems, R. Ramakrishnan and J. Gehrke, ed. McGrawHill, 2000. (2) Bases de Données, G. Gardarin, ed. Eyrolles, 2001.

Plus en détail

Chapitre 1 : Introduction

Chapitre 1 : Introduction Chapitre 1 : Introduction A. Objectifs de l'ouvrage.................. 8 B. Présentation d'oracle11g................. 8 1. Introduction........................ 8 2. Principales nouveautés de la version

Plus en détail

Bases de Données. Plan

Bases de Données. Plan Université Mohammed V- Agdal Ecole Mohammadia d'ingénieurs Rabat Bases de Données Mr N.EL FADDOULI 2014-2015 Plan Généralités: Définition de Bases de Données Le modèle relationnel Algèbre relationnelle

Plus en détail

Introduction aux bases de données relationnelles

Introduction aux bases de données relationnelles Formation «Gestion des données scientifiques : stockage et consultation en utilisant des ases de données» 24 au 27 /06/08 Introduction aux ases de données relationnelles Christine Tranchant-Dureuil UMR

Plus en détail

SQL pour. Oracle 10g. Razvan Bizoï. Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4

SQL pour. Oracle 10g. Razvan Bizoï. Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4 SQL pour Oracle 10g Razvan Bizoï Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4 Ce guide de formation a pour but de vous permettre d'acquérir une bonne connaissance du

Plus en détail

SQL Les fondamentaux du langage (2ième édition)

SQL Les fondamentaux du langage (2ième édition) Introduction 1. Un peu d'histoire 11 2. Les normes SQL 12 3. Description rapide du modèle relationnel 14 3.1 Principaux concepts du modèle relationnel 15 3.2 Principales règles 16 4. Les opérateurs en

Plus en détail

Plan. Cours 4 : Méthodes d accès aux données. Architecture système. Objectifs des SGBD (rappel)

Plan. Cours 4 : Méthodes d accès aux données. Architecture système. Objectifs des SGBD (rappel) UPMC - UFR 99 Licence d informatique 205/206 Module 3I009 Cours 4 : Méthodes d accès aux données Plan Fonctions et structure des SGBD Structures physiques Stockage des données Organisation de fichiers

Plus en détail

Gestion des Journaux. Méthodes d accès aux données. Système d exploitation. Gestion de Verrous. Gestion de. Mémoire. Gestion de transactions Page 2

Gestion des Journaux. Méthodes d accès aux données. Système d exploitation. Gestion de Verrous. Gestion de. Mémoire. Gestion de transactions Page 2 Gestion de Transactions Principes de base Propriétés ACID d'une transaction Protocoles de contrôle de concurrence Protocoles de tolérance aux pannes Gestion de transactions dans Oracle Modèles de transactions

Plus en détail

Les déclencheurs (Triggers) avec Oracle

Les déclencheurs (Triggers) avec Oracle 1) Introduction 2) Événements déclenchant 3) Mécanisme général 4) Privilèges systèmes 5) Syntaxe 6) Nom du déclencheur 7) Option BEFORE ou AFTER 8) Déclencheur LMD 9) Déclencheur LDD 10) Déclencheur d'instance

Plus en détail

2 ème PARTIE : LE LANGAGE SQL

2 ème PARTIE : LE LANGAGE SQL 2 ème PARTIE : LE LANGAGE SQL PLAN : I. Le langage de manipulation des données II. Le langage de définition des données III. Administration de la base de données IV. Divers (HORS PROGRAMME) Introduction:

Plus en détail

Le Network File System de Sun (NFS)

Le Network File System de Sun (NFS) 1 sur 5 Le Network File System de Sun (NFS) Le Network File System de Sun (NFS) Architecture Protocoles Mounting Automounting vs Static mounting Directory et accès aux fichiers Problèmes Implémentation

Plus en détail

Bases de données réparties

Bases de données réparties Bases de données réparties J. Akoka - I. Wattiau 1 Contexte Technologique : des solutions de communication efficace entre les machines des SGBD assurent la transparence des données réparties standardisation

Plus en détail

Introduction aux S.G.B.D.

Introduction aux S.G.B.D. NFE113 Administration et configuration des bases de données - 2010 Introduction aux S.G.B.D. Eric Boniface Sommaire L origine La gestion de fichiers Les S.G.B.D. : définition, principes et architecture

Plus en détail

Réplication des bases de données

Réplication des bases de données Réplication des bases de données Stéphane Gançarski Hubert Naacke LIP6 Université Paris 6 1 Références Livre Articles Cours Principles of Distributed Database Systems Eager Replication [KA 2000]: Bettina

Plus en détail

Notation o i (E) : la transaction i effectue sur l élément E l opération x qui peut être : r lecture (read) w écriture (write)

Notation o i (E) : la transaction i effectue sur l élément E l opération x qui peut être : r lecture (read) w écriture (write) MASTER INFORMATIQUE DE L UNIVERSITÉ BORDEAUX 1 BASES DE DONNÉES AVANCÉES INF 559 (CHRISTIAN RETORÉ) EXERCICES CORRIGÉS ACCÈS CONCURRENTS (31 DÉCEMBRE 2007) Le cours a présenté trois techniques de gestion

Plus en détail

Notes de cours : bases de données distribuées et repliquées

Notes de cours : bases de données distribuées et repliquées Notes de cours : bases de données distribuées et repliquées Loïc Paulevé, Nassim Hadj-Rabia (2009), Pierre Levasseur (2008) Licence professionnelle SIL de Nantes, 2009, version 1 Ces notes ont été élaborées

Plus en détail

SQL pour. Oracle 10g. Razvan Bizoï. Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4

SQL pour. Oracle 10g. Razvan Bizoï. Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4 SQL pour Oracle 10g Razvan Bizoï Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4 La transaction SAVEPOINT Le verrouillage COMMIT Module 14 : Les transactions Objectifs A

Plus en détail

2.1/ Les privilèges sous oracle

2.1/ Les privilèges sous oracle LP Informatique(DA2I), UF7 : Administration Système, Réseaux et Base de données 13/12/2007, Enseignant : M. Nakechbnadi, mail : nakech@free.fr Première parie : Administration d une BD Chapitre 2 : Transaction,

Plus en détail

CYCLE CERTIFIANT ADMINISTRATEUR BASES DE DONNÉES

CYCLE CERTIFIANT ADMINISTRATEUR BASES DE DONNÉES SGBD / Aide à la décision CYCLE CERTIFIANT ADMINISTRATEUR BASES DE DONNÉES Réf: KAO Durée : 15 jours (7 heures) OBJECTIFS DE LA FORMATION Ce cycle complet vous apportera les connaissances nécessaires pour

Plus en détail

Programmation système : sémaphores

Programmation système : sémaphores Programmation système : sémaphores Un sémaphore permet de protéger une variable (ou un type de donnée abstrait) et constitue la méthode utilisée couramment pour restreindre l'accès à des ressources partagées

Plus en détail

EJB avancés. Transactions Sécurité Ressources Performances

EJB avancés. Transactions Sécurité Ressources Performances EJB avancés Transactions Sécurité Ressources Performances Les transactions Concept fondamental dans les applications distribuées Indispensable pour une exécution sure des services Difficile à mettre en

Plus en détail

IFT3030 Base de données. Chapitre 6 SQL. Plan du cours

IFT3030 Base de données. Chapitre 6 SQL. Plan du cours IFT3030 Base de données Chapitre 6 SQL Plan du cours Introduction Architecture Modèles de données Modèle relationnel Algèbre relationnelle SQL Conception Fonctions avancées Concepts avancés Modèle des

Plus en détail

PL/SQL. Pourquoi PL/SQL? Introduction. Principales caractéristiques de PL/SQL. Utilisation de PL/SQL

PL/SQL. Pourquoi PL/SQL? Introduction. Principales caractéristiques de PL/SQL. Utilisation de PL/SQL PL/SQL Avertissement : cette partie du cours n est qu un survol du langage PL/SQL, utile pour écrire des procédures stockées simples Elle laisse de côté de nombreuses fonctionnalités du langage Université

Plus en détail

Modèle relationnel Création et modification des relations en SQL

Modèle relationnel Création et modification des relations en SQL Modèle relationnel Création et modification des relations en SQL ENT - Clé sql2009 BD - Mírian Halfeld-Ferrari p. 1 Insertion dans une relation Pour insérer un tuple dans une relation: insert into Sailors

Plus en détail

Techniques de stockage. Techniques de stockage, P. Rigaux p.1/43

Techniques de stockage. Techniques de stockage, P. Rigaux p.1/43 Techniques de stockage Techniques de stockage, P. Rigaux p.1/43 Techniques de stockage Contenu de ce cours : 1. Stockage de données. Supports, fonctionnement d un disque, technologie RAID 2. Organisation

Plus en détail