• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Bases de données réparties par la pratique
 

Bases de données réparties par la pratique

on

  • 784 views

Bases de données réparties par la pratique: installer, mettre en place et configurer une base une base de données répartie

Bases de données réparties par la pratique: installer, mettre en place et configurer une base une base de données répartie

Statistics

Views

Total Views
784
Views on SlideShare
783
Embed Views
1

Actions

Likes
2
Downloads
31
Comments
1

1 Embed 1

http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • merci Pr abdelouahed Sabri
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Bases de données réparties par la pratique Bases de données réparties par la pratique Presentation Transcript

    • BASES DE DONNÉES RÉPARTIES (BDRÉ) La pratique Abdelouahed Sabri 2011/2012 abdelouahed.sabri@gmail.com 1
    • 2 Introduction Dans un SGBDRé, on suppose que les données soient stockées sur au moins deux sites. Dans ce TP, nous allons utiliser au moins deux ordinateurs (on peut utiliser un ordinateur et une machine virtuelle) avec Oracle installé sur chacun Les deux ordinateurs utilisés doivent être reliés grâce à un réseau TCP/IP Abdelouahed Sabri 2011/2012
    • 3 Introduction Pour se connecter au SGBD Oracle, il faut fournir trois paramètres : Le nom d'utilisateur Le mot de passe L'alias : il renseigne sur plusieurs données à la fois : • Le protocole réseau utilisé pour accéder à la machine cible, • Le nom ou l'adresse de la machine cible sur laquelle se situe le serveur, • Le SID cible ou le nom global de la base, • Le port d'écoute du serveur. Abdelouahed Sabri 2011/2012
    • 4 Introduction Le processus d'écoute Oracle (LISTNER): Le processus d'écoute Oracle est un service permettant à des clients d'utiliser le protocole TCP pour accéder une base de données distante Le fichier de configuration du LISTENR se trouve dans $ORACLE_HOME/Network/Admin/ et se nomme « listener.ora ». Dans ce fichier on peut configurer : • le nom de la machine (HOST), le port (par défaut est 1521) et le nom du service d’écoute (DEFAULT_SERVICE_LISTENER).  Utiliser Oracle Net Manager pour configurer le LISTENER Abdelouahed Sabri 2011/2012
    • 5 Introduction Le processus d'écoute Oracle (LISTNER): Protocole = TCP, HOST = Pc-de-hp, PORT = 1521 DEFAULT_SERVICE_LISTENER = (XE). Abdelouahed Sabri 2011/2012
    • 6 Préparation des utilisateurs Sur chaque site, créer un utilisateur avec les droits suffisants. Sur la machine 1 (le site 1) : utilisateur : BDRE1. Mot de passe : 1111 CREATE USER BDRE1 IDENTIFIED BY "1111"; GRANT ALL PRIVILEGES TO BDRE1; -- ou bien GRANT connect, resource, create view, create database link, create snapshot TO BDRE1; Sur la machine 2 (le site 2) : utilisateur : BDRE2. Mot de passe : 2222 CREATE USER BDRE2 IDENTIFIED BY "2222"; GRANT ALL PRIVILEGES TO BDRE2; Abdelouahed Sabri 2011/2012
    • 7 Les liens de base de données entre les sites Pour interroger une BD distante, il faut créer un lien de base de données. Un lien de base de données est un chemin unidirectionnel d’un serveur à un autre. Un client connecté à une BD A, peut utiliser un lien stocké dans la BD A pour accéder à la BD distante B, mais les utilisateurs connectés à B ne peuvent pas utiliser le même lien pour accéder aux données sur A.  Dans chaque Site on doit créer un lien vers les autres sites. Abdelouahed Sabri 2011/2012
    • 8 Les liens de base de données entre les sites La syntaxe pour la création d’un lien est la suivante: CREATE [SHARED|PUBLIC|PRIVATE] DATABASE LINK Nom_du_Lien CONNECT TO { CURRENT_USER | User IDENTIFIED BY password} USING connect_string ; La clause USING connect_string spécifie le nom de service d’une base distante. Les noms de service d’instances sont stockés dans le fichier de configuration « tnsnames.ora » du serveur distant localisé dans le dossier: «$ORACLE_HOME/Network/Admin/ » Abdelouahed Sabri 2011/2012
    • 9 Les liens de base de données entre les sites Sur le premier site: CREATE PUBLIC DATABASE LINK site1TOsite2 CONNECT TO BDRE2 IDENTIFIED BY "2222" USING '192.168.56.2:1521/XE'; Pour tester le bon fonctionnement du lien: SELECT sysdate FROM dual@site1TOsite2; Sur le deuxième site: CREATE PUBLIC DATABASE LINK site2TOsite1 CONNECT TO BDRE1 IDENTIFIED BY "1111" USING '192.168.56.1:1521/XE'; Pour tester le bon fonctionnement du lien: SELECT sysdate FROM dual@site2TOsite1; Abdelouahed Sabri 2011/2012
    • 10 Les liens de base de données entre les sites Pour supprimer un lien: DROP [SHARED|PUBLIC|PRIVATE] DATABASE LINK nom_du_lien; Pour afficher les liens déjà crées: SELECT * FROM dba_db_links; NB: Lorsqu’un lien est référencé par une instruction SQL, Oracle ouvre une session dans la base distante et y exécute l’instruction La session reste ouverte au cas où elle serait de nouveau nécessaire Abdelouahed Sabri 2011/2012
    • 11 Transparence vis-à-vis de la localisation: Synonymes Pour référencer une base de données dans un système distribué, on utilise le nom global ou le lien de base de données. SELECT sysdate FROM dual@site1TOsite2; Mais afin de converger plus vers l'un des objectifs de la répartition des bases de données qui est la transparence vis-à-vis de la localisation, Oracle utilise des synonymes dont le rôle est de masquer le nom du lien de base de données. Syntaxe: CREATE OR REPLACE [PUBLIC] SYNONYM nom_du_synonyme FOR [schéma.]nom-objet[@Nom_du_Lien] ; Abdelouahed Sabri 2011/2012
    • 12 Transparence vis-à-vis de la localisation: Synonymes Exemple: Sur le premier site: • On suppose qu’il existe une table nommée « perso » sur le site 2. • Sur le site 1, on va créer un synonyme noté « perso » pour cette table sur le site 1 CREATE OR REPLACE PUBLIC SYNONYM perso FOR perso@site1TOsite2; • Pour tester: SELECT *FROM perso; Abdelouahed Sabri 2011/2012
    • 13 Transparence vis-à-vis de la localisation: Synonymes Exemple (suite): Sur le deuxième site: • On suppose qu’il existe une table nommée « profession » sur le site 1. • Sur le site 2, on va créer un synonyme noté « profession » pour cette table sur le site 1 CREATE OR REPLACE profession@site2TOsite1; PUBLIC SYNONYM profession FOR • Pour tester: SELECT *FROM profession ; Pour supprimer un synonyme: DROP SYNONYM nom_du_synonyme; Abdelouahed Sabri 2011/2012
    • 14 Copier les données entre deux bases de données La commande COPY de SQL*Plus permet de copier des données entre deux SGBD’s La meilleure utilisation est d’exécuter cette commande sur la machine où réside la base de données. La syntaxe est la suivante : COPY {FROM database | TO database | FROM database TO database} {APPEND|CREATE|INSERT|REPLACE} destination_table [(column, column, column, ...)] USING query database a la syntaxe suivante: username[/password]@connect_identifier APPEND : si la table n'existe pas (CREATE + INSERT) sinon (INSERT) CREATE : si la table n'existe pas (CREATE + INSERT) sinon (erreur) REPLACE : si la table n'existe pas (CREATE + INSERT) sinon (DROP + CREATE + INSERT) INSERT : si la table n'existe pas (ERREUR) sinon (INSERT) NB: La commande COPY n’exporte pas les contraintes (sauf NOT NULL) Exemple: COPY FROM BDRE1/1111@192.168.56.1/XE TO BDRE2/2222@192.168.56.2/XE REPLACE Agence USING SELECT *FROM Agence; Abdelouahed Sabri 2011/2012
    • 15 Transparence vis-à-vis de la fragmentation: Vues Un des principaux objectifs de bases de données réparties est la transparence à la fragmentation. Ainsi, même fragmentés, les enregistrements doivent apparaitre comme sur un seul site. Pour ceci, on utilise les vues : View Les utilisateurs pourront consulter la base, ou modifier la base (avec certaines restrictions) à travers la vue, c'est-à-dire manipuler la table résultat du SELECT comme si c'était une table réelle. La syntaxe pour créer une vue est la suivante : CREATE VIEW nom_vue [(nom_col1,...)] AS SELECT ... [WITH CHECK OPTION]; Abdelouahed Sabri 2011/2012
    • 16 Transparence vis-à-vis de la fragmentation: Vues (suite) Exemple : Création d'une vue constituant une restriction de la table emp aux employés du département 10. CREATE VIEW emp10 AS SELECT * FROM emp WHERE n_dept = 10;  INSERT INTO emp10 VALUES (15, 'Mohamed‘, 25, 25); Equivalent à : INSERT INTO emp VALUES (15, 'Mohamed‘, 25, 25); Exemple : CREATE VIEW emp10 AS SELECT * FROM emp WHERE n_dept = 10 WITH CHECK OPTION ; Les insertion et modification suivantes ne sont pas autorisées: INSERT INTO emp10 VALUES (15, 'Mohamed‘, 45, 25); UPDATE emp SET n_dept =25; Abdelouahed Sabri 2011/2012
    • 17 Transparence vis-à-vis de la fragmentation: Vues (suite) Pour supprimer une vue DROP VIEW nom_vue; Pour renommer une vue : RENAME ancien_nom TO nouveau_nom Abdelouahed Sabri 2011/2012
    • 18 Transparence vis-à-vis de la fragmentation: Vues (suite) Certaines vues peuvent être l’objet de mise à jour par les instructions INSERT, UPDATE, DELETE. Les restrictions imposées par Oracle sur la requête de la vue afin que celle-ci soit modifiable : • • • • • Pas d’opérateurs ensemblistes Pas de fonction d’agrégation Pas de clause group by ou order by Pas de sous-requête Pas de collection dans un select (objet-relationnel) Dans le cas contraire, on fait appel aux déclencheurs INSTEAD OF.  Les triggers INSTEAD OF prennent la main et font les mises à jour sur les fragments distants. Abdelouahed Sabri 2011/2012
    • 19 Transparence vis-à-vis de la fragmentation: Les triggers INSTEAD OF La syntaxe est la suivante: CREATE TRIGGER nom_du_declencheur INSTEAD OF {INSERT | UPDATE | DELETE} ON nom_de_la_vue FOR EACH ROW BEGIN … END ; Exemple CREATE TRIGGER tr_emp10 INSTEAD OF INSERT ON emp10 FOR EACH ROW BEGIN INSERT INTO emp VALUES (:new.NO, :new.nom, :new.n_dept,:new.age); END ; Abdelouahed Sabri 2011/2012
    • 20 Duplication La première option consiste à répliquer régulièrement les données sur le serveur local. Duplication synchrone: diffuser immédiatement les modifications apportées aux données sources vers les copies • Utilisation des TRIGGER ou TRIGGER INSTEAD OF Duplication asynchrone: diffuser les modifications apportées aux données sources vers les copies à des intervalles prédéfinis. • utilisation de SNAPSHOT (clichés) ou Mateliarised view (vues matérialisées) Abdelouahed Sabri 2011/2012
    • 21 Duplication Asynchrone Snapshots: Un snapshot est une copie conforme d'une table (ou plusieurs) située sur une base de donnée du système distribué Il permet de diminuer les coûts réseau, en rendant local les données situées à distance • Afin d'assurer la cohérence de données, une mise à jour régulière et automatique est effectuée à partir du site d'origine ou MASTER 2 types: en lecture seule (read-only) ou mis à jour (updateable) Abdelouahed Sabri 2011/2012
    • 22 Duplication Asynchrone (suite) Les read-only Snapshots: non modifiables à partir du site esclave. Syntaxe: CREATE SNAPSHOT nom_snapshot [REFRESH FAST | COMPLETE | FORCE] START WITH date_de_debut_de_synchronisation NEXT date_de_la_prochaine_synchronisation AS requéte_select; FAST: Le mode rapide permet de faire un rafraîchissement en tenant compte seulement des mises à jour effectuées sur le site Maître.  Un SNAPSHOT LOG doit être crée pour la table Maître afin de noter les différents changements subvenus qui seront répercutés sur le snapshot: CREATE SNAPSHOT LOG ON nom_de_la_table; Abdelouahed Sabri 2011/2012
    • 23 Duplication Asynchrone (suite) Les read-only Snapshots: non modifiables à partir du site esclave. Syntaxe: CREATE SNAPSHOT nom_snapshot [REFRESH FAST | COMPLETE | FORCE] START WITH date_de_debut_de_synchronisation NEXT date_de_la_prochaine_synchronisation AS requéte_select; COMPLETE: à chaque rafraîchissement, toute la table est transférée.  Ce mode est obligatoire pour les snapshots complexes, NB:  Un snapshot est dit simple si la requête SELECT ne contient pas d’opération ensemblistes ni de clause ORDER BY  Un snapshot est dit complexe dans le cas contraire Abdelouahed Sabri 2011/2012
    • 24 Duplication Asynchrone (suite) Les read-only Snapshots: non modifiables à partir du site esclave. Syntaxe: CREATE SNAPSHOT nom_snapshot [REFRESH FAST | COMPLETE | FORCE] START WITH date_de_debut_de_synchronisation NEXT date_de_la_prochaine_synchronisation AS requéte_select; FORCE: Un rafraîchissement rapide est d'abords tenté; s'il ne marche pas le rafraîchissement complet est effectué. Abdelouahed Sabri 2011/2012
    • 25 Duplication Asynchrone (suite) Les read-only Snapshots: non modifiables à partir du site esclave. Syntaxe: CREATE SNAPSHOT nom_snapshot [REFRESH FAST | COMPLETE | FORCE] START WITH date_de_debut_de_synchronisation NEXT date_de_la_prochaine_synchronisation AS requéte_select; Exemple: CREATE SNAPSHOT emp_snap_fast REFRESH FAST START WITH Sysdate NEXT Systdate + 1 AS SELECT * FROM emp@site1tosite2 WHERE n_dept = 10 ; NB: les table emp doit avoir une clef primaire Abdelouahed Sabri 2011/2012
    • 26 Duplication Asynchrone (suite) Les updateable Snapshots: Les snapshots de mise à jour peuvent être directement modifiés. Dans ce cas, les données mises à jour à leur niveau sont répliquées vers le site Master lors du processus de rafraîchissement. Syntaxe: CREATE SNAPSHOT nom_snapshot [REFRESH FAST | COMPLETE | FORCE] START WITH date_de_debut_de_synchronisation NEXT date_de_la_prochaine_synchronisation ENABLE QUERY REWRITE AS requéte_select; Exemple: CREATE materialized view emp_snap_fast REFRESH COMPLETE START WITH Sysdate NEXT Sysdate + 1 Enable QUERY REWRITE AS SELECT ID, NOM FROM emp@site1tosite2 WHERE n_dept = 10 ; Abdelouahed Sabri 2011/2012
    • 27 Duplication Asynchrone (suite) Modifier une vue matérialisée ALTER materialized view nom_snapshot [REFRESH FAST | COMPLETE | FORCE] START WITH date_de_debut_de_synchronisation NEXT date_de_la_prochaine_synchronisation; Abdelouahed Sabri 2011/2012