Bases de données réparties par la pratique

BASES DE DONNÉES RÉPARTIES

(BDRÉ)

La pratique

Abdelouahed Sabri 2011/2012

abdelouahed.sabri@gmail.com

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.

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;

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.

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

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

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:

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.

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

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;

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:

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

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;

Vues (suite)

Pour supprimer une vue

DROP VIEW nom_vue;

Pour renommer une vue :

RENAME ancien_nom TO nouveau_nom

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} ON nom_de_la_vue

FOR EACH ROW

CREATE TRIGGER tr_emp10

INSTEAD OF INSERT ON emp10

FOR EACH ROW

INSERT INTO emp VALUES (:new.NO, :new.nom, :new.n_dept,:new.age);

Exemple

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)

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)

DuplicationAsynchrone (suite)

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

esclave.

Syntaxe:

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;

esclave.

Syntaxe:

AS requéte_select;

COMPLETE: à chaque rafraîchissement, toute la table est transférée.

Ce mode est obligatoire pour les snapshots complexes,

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

esclave.

Syntaxe:

AS requéte_select;

FORCE: Un rafraîchissement rapide est d'abords tenté; s'il ne marche pas le rafraîchissement

complet est effectué.

esclave.

Syntaxe:

CREATE SNAPSHOT emp_snap_fast

REFRESH FAST START WITH Sysdate NEXT Systdate + 1

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

Exemple:

AS requéte_select;

NB: les table emp doit avoir une clef primaire

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:

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:

Duplication

Asynchrone (suite)

Modifier une vue matérialisée

ALTER materialized view nom_snapshot

NEXT date_de_la_prochaine_synchronisation;

Bases de données réparties par la pratique

Education

Transport de contenu multimédia · Gestion du nombre de flux • Les données multimédia sont réparties en plusieurs flux parallèles • Efficacité de la distribution • Conservation

Institut Universitaire de Technologie - iut-larochelle.fr fileGestion de bases de données réparties Réseau et mobilité ... (Développeur ou Administrateur de Réseaux ... et la

Guide pratique - chapters.theiia.org pratique - Cloud computing et protection des données 3 Sommaire • Sommaire • Avant-propos • Synthèse • Préambule • Termes clés -

Bases de Données Réparties Concepts et Techniquesicps.u-strasbg.fr/.../enseignement/m2ria/exbrayat/Bdrep1-bases.pdf · Une base de données répartie (distribuée) est une base

Guide pratique sur l’utilisation de données à caractère

Cours pour les Master I Les BDAs (Les bases de données réparties)

Bases de données et sites WEB Cours1 : Transactions en pratique

Guide pratique spécifique à la destruction de données lors

Base de données réparties

CATALOGUES DE DONNÉES OUVERTESdata.ec.gc.ca/data/sites/emergencies/shoreline-segmentation-with... · 1 GUIDE PRATIQUE – NAVIGUER À TRAVERS LES CATALOGUES DE DONNÉES OUVERTES

Bases de Données Réparties 1. Définition 2. Architectures 3. Conception de BDR 4. Traitement des requêtes 5. Transaction répartie 6. Passerelles avec autres

Master d’Informatique BDR - 4I803 – COURS 5 · 2016 2 Bases de Données Réparties • Définition • Conception ... (catalogue, métabase) réparties ... • Ref biblio récente

La visualisation de données : étudier une pratique de terrain · La visualisation de données : étudier une pratique de terrain ... - Mettre les critiques au centre des questionnements

Cloud Computing et Protection des Données - Guide pratique

Guide pratique RGPD - Délégués à la protection des données

COURS INFORMATIQUE - Guide pratique de récupération de données sur disque dur

Introduction pratique aux bases - academiepro.com · Andreas Meier Introduction pratique aux bases de données relationnelles Deuxième édition Traduit de l’allemand par : Dac

Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

Données, création : approche pratique. Base de données, logiciel, bien

HTA: Des données des essais cliniques à la décision pratique