27
BASES DE DONNÉES RÉPARTIES (BDRÉ) La pratique Abdelouahed Sabri 2011/2012 [email protected] 1

Bases de données réparties par la pratique

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Bases de données réparties par la pratique

BASES DE DONNÉES RÉPARTIES

(BDRÉ)

La pratique

Abdelouahed Sabri 2011/2012

[email protected]

1

Page 2: Bases de données réparties par la pratique

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

2

Page 3: Bases de données réparties par la pratique

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

3

Page 4: Bases de données réparties par la pratique

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

4

Page 5: Bases de données réparties par la pratique

Introduction

Le processus d'écoute Oracle (LISTNER):

Abdelouahed Sabri 2011/2012

5

Protocole = TCP,

HOST = Pc-de-hp,

PORT = 1521

DEFAULT_SERVICE_LISTENER = (XE).

Page 6: Bases de données réparties par la pratique

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

Abdelouahed Sabri 2011/2012

6

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;

Page 7: Bases de données réparties par la pratique

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

7

Page 8: Bases de données réparties par la pratique

Les liens de base de données entre les sites

La syntaxe pour la création d’un lien est la suivante:

Abdelouahed Sabri 2011/2012

8

CREATE [SHARED|PUBLIC|PRIVATE] DATABASE LINK Nom_du_LienCONNECT 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/ »

Page 9: Bases de données réparties par la pratique

Les liens de base de données entre les sites

Sur le premier site:

Abdelouahed Sabri 2011/2012

9

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;

Page 10: Bases de données réparties par la pratique

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

10

Page 11: Bases de données réparties par la pratique

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:

Abdelouahed Sabri 2011/2012

11

CREATE OR REPLACE [PUBLIC] SYNONYM nom_du_synonyme

FOR [schéma.]nom-objet[@Nom_du_Lien] ;

Page 12: Bases de données réparties par la pratique

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

12

Page 13: Bases de données réparties par la pratique

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;

Abdelouahed Sabri 2011/2012

13

Page 14: Bases de données réparties par la pratique

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 :

Abdelouahed Sabri 2011/2012

14

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/[email protected]/XE TO BDRE2/[email protected]/XE REPLACE Agence

USING SELECT *FROM Agence;

Page 15: Bases de données réparties par la pratique

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 :

Abdelouahed Sabri 2011/2012

15

CREATE VIEW nom_vue [(nom_col1,...)]

AS SELECT ...

[WITH CHECK OPTION];

Page 16: Bases de données réparties par la pratique

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

16

Page 17: Bases de données réparties par la pratique

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

17

Page 18: Bases de données réparties par la pratique

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

18

Page 19: Bases de données réparties par la pratique

Transparence vis-à-vis de la fragmentation: Les triggers INSTEAD OF

La syntaxe est la suivante:

Abdelouahed Sabri 2011/2012

19

CREATE TRIGGER nom_du_declencheur

INSTEAD OF {INSERT | UPDATE | DELETE} ON nom_de_la_vue

FOR EACH ROW

BEGIN

END ;

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 ;

Exemple

Page 20: Bases de données réparties par la pratique

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

20

Page 21: Bases de données réparties par la pratique

DuplicationAsynchrone

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

21

Page 22: Bases de données réparties par la pratique

DuplicationAsynchrone (suite)

Les read-only Snapshots: non modifiables à partir du site

esclave.

Syntaxe:

Abdelouahed Sabri 2011/2012

22

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;

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;

Page 23: Bases de données réparties par la pratique

DuplicationAsynchrone (suite)

Les read-only Snapshots: non modifiables à partir du site

esclave.

Syntaxe:

Abdelouahed Sabri 2011/2012

23

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

Page 24: Bases de données réparties par la pratique

DuplicationAsynchrone (suite)

Les read-only Snapshots: non modifiables à partir du site

esclave.

Syntaxe:

Abdelouahed Sabri 2011/2012

24

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

Page 25: Bases de données réparties par la pratique

DuplicationAsynchrone (suite)

Les read-only Snapshots: non modifiables à partir du site

esclave.

Syntaxe:

Abdelouahed Sabri 2011/2012

25

CREATE SNAPSHOT emp_snap_fast

REFRESH FAST START WITH Sysdate NEXT Systdate + 1

AS SELECT * FROM emp@site1tosite2 WHERE n_dept = 10 ;

Exemple:

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;

NB: les table emp doit avoir une clef primaire

Page 26: Bases de données réparties par la pratique

DuplicationAsynchrone (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:

Abdelouahed Sabri 2011/2012

26

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;

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 ;

Exemple:

Page 27: Bases de données réparties par la pratique

Duplication

Asynchrone (suite)

Modifier une vue matérialisée

Abdelouahed Sabri 2011/2012

27

ALTER materialized view nom_snapshot

[REFRESH FAST | COMPLETE | FORCE]

START WITH date_de_debut_de_synchronisation

NEXT date_de_la_prochaine_synchronisation;