BASES DE DONNÉES DISTRIBUÉES

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
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.
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
Introduction
Le processus d'écoute Oracle (LISTNER):

Protocole = TCP,
HOST = Pc-de-hp,
PORT = 1521
 DEFAULT_SERVICE_LISTENER = (XE).

Préparation des utilisateurs

Sur chaque site, créer un utilisateur avec les droits suffisants.
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;

Sur la machine 1 (le site 1) : utilisateur : BDRE1. Mot de passe : 1111

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.
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/ »
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;

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

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] ;
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;
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 PUBLIC SYNONYM profession FOR

profession@site2TOsite1;

• Pour tester:
SELECT *FROM profession ;
 Pour supprimer un synonyme:
DROP SYNONYM nom_du_synonyme;

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;

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

La syntaxe pour créer une vue est la suivante :

CREATE VIEW nom_vue [(nom_col1,...)]
AS SELECT ...
[WITH CHECK OPTION];
 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.
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;

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
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.
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} ONnom_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 ;
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)

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)
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;

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
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é.
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 WITHSysdate NEXT Systdate + 1
AS SELECT * FROM emp@site1tosite2 WHERE n_dept = 10 ;

NB: les table emp doit avoir une clef primaire

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