7/2 Architecture de bases de données distribuées Oracle 7/2.1

7/2 Architecture de bases de données distribuées Oracle
7/2.1 Concepts de base
Introduction
Une base de données distribuée est un ensemble de bases de données autonomes partageant leurs
données. Elles peuvent s'exécuter sur des machines différentes, chacune étant contrôlée par un
Serveur. Les différents serveurs impliqués coopèrent pour maintenir la cohérence de la base de
données globale.
Tous les serveurs et les clients sont dans une architecture Client/Serveur, ce qui permet à n'importe
quel Client de se connecter à n'importe quel Serveur.
La distribution des bases de données permet, entre autres, une plus grande spécialisation des bases
autonomes. On peut, en effet, introduire des séparations par domaines fonctionnels ou selon d'autres
critères. Cette spécialisation permet de réduire considérablement le trafic réseau (cf. Fig. 1).
Exemple de base de données distribuée.
Noms globaux
Les objets sont définis par des noms uniques dans les bases de données autonomes. L'unicité des
noms d'objets est donc assurée au niveau local.
Pour se référer à un objet se trouvant dans une base autonome, à partir d'une autre base autonome,
on utilise les conventions internet :
objet@nom_global_de_base_de_données
Page 1/17
Le nom global d'une base de données autonome se compose comme suit :
nom_de_base_de_donnée.nom_de_domaine
Le nom_domaine est le nom du domaine réseau auquel appartient la base. Pour créer des domaines
réseau, on utilise le Network Domain Service. Par défaut, Oracle crée un domaine réseau qui
s'appelle WORLD.
Liens de bases de données
Pour atteindre des objets situés sur une base autonome à partir d'une autre (appartenant à la même
base de données distribuée), Oracle utilise la notion de liens de bases de données.
Un lien de base de données est un chemin de la base en cours vers une base distante de manière
transparente pour l'utilisateur.
Autonomie des sites
Chaque serveur participant à la base de données distribuée est administré séparément et
indépendamment des autres serveurs, c'est ce qu'on appelle l'autonomie des sites. Ceci permet une
administration locale et la réduction des domaines de responsabilité.
Transparence
Elle est de trois types :
1.
Transparence
à
la
localisation
Dans une base de données distribuée, les objets sont par définition localisés dans différents
noeuds du réseau. Ceci impose une contrainte aux applications clientes, celle d'indiquer (et donc
de connaître) pour chaque objet le noeud sur lequel il se trouve. De plus, chaque déplacement
d'objet aura un impact direct sur les applications l'utilisant. Pour y remédier, des méthodes
permettent d'accéder aux objets distribués, l'application cliente n'a pas à spécifier la localisation
physique de l'objet. C'est ce qu'on appelle la transparence à la localisation.
2.
Transparence
au
mécanisme
de
C'est Oracle qui garantit l'atomicité des transactions distribuées.
3.
Transparence
à
la
réplication
Dans certains cas, on est amené à dupliquer des objets sur plusieurs sites, par exemple pour des
tables fréquemment consultées mais peu mises à jour, une duplication réduit le trafic réseau.
Parfois, pour de simples raisons de sécurité et de tolérance aux pannes, les bases sont
dupliquées. La transparence à la réplication consiste alors en la maintenance de ces copies sans
intervention de l'administrateur.
la
transaction
Propagation
La propagation est la mise à jour des différents noeuds de façon à garder la base de données globale
cohérente.
On distingue deux méthodes de propagation :
1.
o
Propagation
synchrone
À chaque mise à jour, la modification est immédiatement propagée sur tous les noeuds. Ceci
permet de disposer, à tout instant, de données à jour sur l'ensemble des sites. Mais dans ce cas,
les sites sont fortement dépendants :
– une panne sur un site entraîne l'arrêt de tous les autres sites ;
Page 2/17
o
– les mises à jour, même si elles sont locales, sont très lentes car il faut attendre la
mise à jour des autres sites.
2.
Propagation
asynchrone
Les sites sont indépendants les uns des autres. Mais cette forte autonomie des sites présente
l'inconvénient de ne pas disposer immédiatement des dernières mises à jour des données, et
surtout, ce type de propagation peut autoriser des conflits de mise à jour. On a alors besoin de
mettre en place des techniques, souvent compliquées, de détection et de résolution des conflits.
Données réparties
Dans une configuration répartie (propagation synchrone forcément), chaque site possède un sousensemble distinct de données ; il n'y a qu'une seule copie physique de chaque donnée. Du coup, les
performances des requêtes distribuées (devant accéder à plusieurs sites distants) sont affectées, et si
un site devient indisponible, il est impossible d'exécuter des transactions distribuées.
Données répliquées
Dans un environnement distribué avec données répliquées, chaque site possède une copie des
données auxquelles il accède. Dans une telle configuration, plusieurs sites peuvent modifier des
copies de la même donnée, ce qui dans un mode synchrone limite l'accès aux données. Il est donc
préférable de choisir un mode asynchrone pour une configuration répliquée.
Les techniques de réplication
Elles agissent selon 2 modèles :
1.
Modèle
à
propriété
unique
Les données sont la propriété d'un seul site, il n'y a donc pas de conflit de mise à jour.
Le modèle de base stipule que le site propriétaire de données est invariable, c'est le site primaire,
tous les autres sites
snapshots
n'ont
accès aux données
qu'en
lecture.
Pour des raisons de performances, le modèle élaboré permet des mises à jour locales sur des
parties distinctes de tables dites fragments dont le site est propriétaire. L'unicité de la propriété
peut être assurée par un mélange de déclencheurs, vues, procédures stockées et Updatable
Snapshots.
Le modèle dynamique fait évoluer dans le temps le site propriétaire de chaque donnée.
2.
Modèle
à
propriété
partagée
Ce modèle permet qu'à un moment précis les données soient globalement incohérentes, mais il a
l'avantage d'être, en mode asynchrone, tolérant aux pannes.
Réduction de la redondance
D'un côté, la localité des applications est augmentée si les données sont recopiées dans tous les sites
où elles sont nécessaires, la disponibilité du système croît puisque l'arrêt d'un site n'entraîne pas
l'arrêt des autres.
De l'autre, pour éviter l'incohérence entre plusieurs copies et utiliser le moins d'espace de stockage,
on est tenté de réduire la redondance. Conclusion : l'intérêt de la redondance augmente comme le
rapport des recherches aux mises à jour ; s'il y a plus de mises à jour de données que de recherches,
il vaut mieux accroître la redondance et inversement.
7/2.2 Le cas Oracle
7/2.2.1 Noms globaux
Page 3/17
Oracle assure l'unicité des noms des objets au niveau des schémas. Pour éviter toute ambiguïté au
niveau de la base de données Oracle, on utilise la notation suivante :
schéma.objet
Noms d'objets globaux
Pour une base de données distribuée, on utilise une notation plus complète en introduisant la notion
de noms d'objets globaux :
schéma.objet@ base_de_donnée.domaine
Gestion des noms de domaine
Oracle propose un utilitaire pour gérer les noms de domaine : Network Domain Service qui permet
de créer des domaines et assure l'unicité des noms globaux des bases de données. Si le Network
Domain Service n'est pas disponible, on peut créer des noms globaux de base de données
manuellement. Mais il vaut mieux utiliser les liens de base de données (Database Links).
7/2.2.2 Liens de bases de données
Les types de lien de base de données
Il existe trois types de liens de bases de données :
1.
Lien de base de données privé : il ne peut être utilisé que par l'utilisateur l'ayant créé.
2.
Lien de base de données public : il est créé par le groupe d'utilisateurs spécial Public, il peut
être utilisé par n'importe quel utilisateur de la base de données où il a été défini ;
3.
Lien de base de données réseau : il est créé par un Network Domain Service ; il peut être
utilisé par n'importe quel utilisateur de n'importe quelle base de données appartenant au réseau.
Création d'un lien de base de données
Pour créer un lien de base de données privé, il faut posséder le privilège système Create Database
Link.
Pour créer un lien de base de données public, il faut posséder le privilège système Create Public
Database Link
La commande permettant de créer un lien de base de données public est :
CREATE PUBLIC DATABASE LINK nom_lien_de_base_de_données
CONNECT TO utilisateur IDENTIFIED BY mot_de_passe
USING 'base_de_données'
Pour un lien de base de données privé, il faut remplacer le mot clé PUBLIC par le mot clé PRIVE
La clause CONNECT TO ... IDENTIFIED BY ... est optionnelle, elle représente l'utilisateur sous lequel
Oracle tentera d'effectuer la connexion vers la base de données distante. Lorsqu'une instruction SQL
Page 4/17
spécifie un nom d'objet global, Oracle tentera d'établir une session pour l'utilisateur spécifié dans le
lien. C'est une connexion utilisant un compte central (cf. Fig. 1).
Si aucun utilisateur n'est spécifié, Oracle tentera alors d'établir une session dans la base distante avec
le nom et le mot de passe de l'utilisateur connecté à la base de données locale, il s'agit d'une
connexion utilisant un compte individuel (cf. Fig. 2).
Création de lien de base de données utilisant un compte central.
Création d'un lien de base de données utilisant un compte individuel.
L'utilisation d'un compte central dans un lien de base de données
Elle est peut-être plus facile mais offre moins de sécurité que l'utilisation d'un compte individuel. En
effet, des utilisateurs peuvent se retrouver connectés à la base distante avec des privilèges qui
n'auraient pas dû leur être attribués. Mais dans tous les cas, il faut que l'utilisateur spécifié dans le lien
de base de données possède les privilèges nécessaires à l'exécution de la requête.
Pour supprimer un lien de base de données
Page 5/17
Il suffit d'exécuter la requête :
DROP DATABASE LINK nom_du_lien
7/2.2.3 Transparence
Création des liens de bases de données
Il est de la responsabilité de l'administrateur de base de données ou du responsable d'une application
de créer les liens de bases de données nécessaires et de créer les vues, synonymes ou procédures
permettant aux utilisateurs et aux applications de ne plus se soucier de la localisation des objets qu'ils
manipulent.
Exemple
La définition d'un synonyme peut cacher entièrement la localisation de l'objet CREATE PUBLIC
SYNONYME synonyme_objet FOR schemas.table@liens_de_base_de_données.
Recherche des liens de bases de données
Oracle recherche les liens de base de données dans l'ordre suivant :



– liens de base de données privés dans le schéma de l'utilisateur localement connecté ;
– liens de base de données publics dans la base de données locale ;
– et si le Network domain service existe, Oracle recherche un lien de base de données
réseau.
7/2.2.4 Connexions
Il existe deux types de connexions : directe et indirecte.
Exemple
SQLPLUS utilisateur/mot_de_passe@bd1
Connexion directe
Elle s'effectue par la commande suivante : SELECT * FROM table1
Connexion indirecte
Elle s'effectue par la commande suivante : SELECT * FROM [email protected]
Explications
Dans les deux exemples, le Client CL1 formule sa requête au Serveur s1. Dans le premier exemple s1
répond lui-même à la requête, dans le second, c'est le Serveur s1 qui devient à son tour Client et
formule une requête au Serveur s2 qui lui répond puis le Serveur s1 transmet la réponse au Client
CL1. Le Client CL1 n'a même pas besoin d'avoir une connexion vers le Serveur s2.
7/3 Réplication
Page 6/17
La réplication est un processus de copie et d'enregistrement d'objets de bases de données
autonomes dans d'autres bases de données autonomes, formant une base de données distribuée.
Amélioration des performances du système
La réplication peut améliorer la performance du système. En effet, une application qui accéderait
normalement à une base de données locale au lieu d'un serveur distant permet :



– l'amélioration des performances de recherche, puisque les données sont accédées
localement ;
– la diminution du trafic réseau, le transfert des données étant différé (planifié à des heures
creuses) ;
– une plus grande tolérance aux pannes (possibilité de reprise sur incident : la réplication peut
protéger la disponibilité des applications, car elle assure des options d'accès aux données de
rechange. L'application peut continuer de fonctionner lors d'une défaillance du serveur local, les autres
serveurs qui contiennent les données répliquées demeurant accessibles.
Les types de réplication
Oracle prend en charge deux types de réplication :


– la réplication de base, en lecture seule (Read-only snapshot) ;
– la réplication évoluée, symétrique.
7/3.1 Réplication de base : snapshot en lecture seule (Read-only snapshot)
7/3.1.1 Définition
Un snapshot (jeu de données) est une copie locale d'un ou plusieurs objets distants, qui proviennent
d'un site principal (site maître).
Les read-only snapshots sont très utiles dans plusieurs types d'applications :



– diffusion de l'information ;
– sauvegarde des données ;
– échange ou transfert de données.
Diffusion de l'information
La réplication de base constitue une option efficace pour la diffusion de l'information. Prenons le cas
d'un opérateur en téléphonie mobile qui souhaite diffuser une information complète et mise à jour sur
ses tarifications, à intervalles de temps régulier, auprès de ses revendeurs sur l'ensemble du territoire.
Dans ce secteur d'activité, il est essentiel de s'assurer que les informations sur les prix sont
disponibles en tout temps, qu'elles sont à jour et qu'elles sont identiques sur tous les points de vente.
Pour ce faire, chaque point de vente peut conserver ses propres tables de prix qu'il régénère tous les
soirs à partir de la table de prix principale du siège social de l'opérateur.
Sauvegarde des données
La réplication de base permet de répliquer une base de données complète ou de stocker des données
quelque part en vue d'une autre utilisation. Par exemple, pour la mise en place d'un système
Page 7/17
décisionnel, il est souvent recommandé de créer un répliquât de la base de données de production,
afin d'isoler les interrogations qui proviennent des applications d'aide à la décision, qui accaparent
fortement le système.
Échange ou transfert des informations
La réplication de base peut constituer un outil de transfert des données, par exemple, dans un
contexte d'entreprise étendue, un répliquât chez le client ou le fournisseur permet de transférer des
données de facturation ou de commande régulièrement.
7/3.1.2 Types de read-only snapshots
On distingue deux types de read-only snapshots :
read-only snapshots simples
Il s'agit d'une copie enregistrement à enregistrement, par exemple la copie d'une table telle quelle ;
read-only snapshots complexes
Il s'agit d'une copie du résultat d'une requête contenant une des clauses GROUPE BY, CONNECT
BY, jointure, sous-requête ou opération SET.
Ce type est très utile quand on cherche à obtenir des données agrégées, donc un temps de réponse
relativement faible en consultation.
7/3.1.3 Rafraîchissement des read-only snapshots
Il existe trois types de rafraîchissements possibles.
Rafraîchissement complet (complete)
Le snapshot est réinitialisé à vide avant chaque mise à jour (les données du snapshot sont
complètement remplacées).
Rafraîchissement rapide (fast)
Il ne s'applique qu'aux read-only snapshots simples. Il permet d'obtenir les informations de mises à
jour de l'objet maître depuis le dernier rafraîchissement. Pour cela, il utilise une table log qui
rassemble ces informations.
Rafraîchissement forcé (force)
Il s'agit d'un rafraîchissement rapide et à défaut un rafraîchissement complet.
Les rafraîchissements peuvent être manuels ou automatiques, dans ce dernier cas il faut spécifier la
date du premier rafraîchissement dans la START et un intervalle de temps dans la clause NEXT de la
commande CREATE SNAPSHOT.
Syntaxe
Page 8/17
Les mots clés COMPLETE, FAST ou FORCE doivent être spécifié dans la clause REFRESH de la
commande CREATE SNAPSHOT ou ALTER SNAPSHOT.
7/3.1.4 Mécanismes des read-only snapshots
À la création d'un read-only snapshot
Oracle crée automatiquement dans la base locale :



– une table de base appelée SNAP$nom_snapshot pour contenir les enregistrements
retournés par la requête définissant le read-only snapshot ;
– une vue sur la table de base, pour les utilisateurs, qui porte le nom du read-only snapshot
nom_snapshot ;
– une seconde vue basée sur la table maître du site distant, appelée
MVIEW$_nom_snapshot, utilisée lors du rafraîchissement du read-only snapshot.
Pour les snapshots simples
Oracle crée également :

– un index appelé I_SNAP$_nom_snapshot basé sur le ROWID de la table de base
SNAP$nom_snapshot.
Pour les snapshots simples, utilisant l'option rafraîchissement rapide
On peut demander à Oracle de créer :


– un snapshot log qui est appelé MLOG$_nom_table_maître ;
– un trigger utilisé pour déclencher et mettre à jour
TLOG$_nom_table_maître.
ce
snapshot log, appelé
Chaque fois que la table maître de la base de données distante est modifiée, Oracle place ces
changements dans le snapshot log. Ces informations permettront d'effectuer des rafraîchissements
rapides d'un snapshot simple.
7/3.1.5 Création d'un read-only snapshot
Pour pouvoir créer un read-only snapshot, il faut posséder les privilèges système CREATE
SNAPSHOT, CREATE TABLE, CREATE VIEW et SELECT sur les tables maîtres.
Exemple de création d'un read-only snapshot avec rafraîchissement rapide
Reprenons notre exemple pour créer sur la base bd3, du Serveur s2 un read-only snapshot appelé
emp_ros qui sera utilisé pour répliquer les données de la table Scott.EMP située dans la base de
données bd1 du serveur s1, avec l'option rafraîchissement rapide.
Pour commencer, on doit créer le lien de base de données bd1_dbl.world, de la base bd3 vers la
base bd1, permettant d'atteindre les données répliquées.
Sur le serveur s2, base bd3, on lance les requêtes suivantes :
CONNECT scott/tiger@bd3_orcl ;
CREATE DATABASE LINK bd1_dbl.world
Page 9/17
CONNECT TO scott IDENTIFIED BY tiger
USING 'bdl_orcl' ;
CREATE SNAPSHOT emp_ros
REFRESH FAST
START WITH SYSDATE
NEXT SYSDATE + 7
AS SELECT * FROM scott.emp@bd1_bdl.world ;
Voici les objets que Oracle crée :
SELECT object_name object_type FROM user_objects WHERE object_name LIKE '%e
mp_ros' ;
Bd3
Bd1
I_SNAP$_EMP_ROS
INDEX
SNAP$_EMP_ROS
TABLE
EMP_ROS
VIEW
MVIEW$_EMP_ROS
VIEW
Rien
Exemple de création d'un read-only snapshot complexe avec rafraîchissement complet
Pour créer un read-only snapshot complexe avec rafraîchissement complet :
Sur la base bd3 du serveur s2, on exécute la requête suivante :
CREATE SNAPSHOT ED_ROS
REFRESH COMPLETE
START WITH SYSDATE
NEXT SYSDATE + 7
AS SELECT... FROM scott.emp@bd1_bdl.world E, scott.dep@bd1_bdl.world D
WHERE D. empno = E.empno ;
Voici les objets que Oracle crée :
Bd3
Bd1
I_SNAP$_ED_ROS
INDEX
SNAP$_ED_ROS
TABLE
ED_ROS
VIEW
MVIEW$_ED_ROS
VIEW
Rien
Page 10/17
7/3.1.6 Création et utilisation d'un journal de snapshot (snapshot log)
Lorsqu'une table maître sert à créer un ou plusieurs snapshots simples, on peut créer un snapshot log
pour cette table, qui permettra d'utiliser l'option de rafraîchissement rapide des snapshots.
Définition de snapshot log
C'est une table située dans la même base de données que la table maître, qui consigne les
informations relatives aux modifications apportées à la table maître et des informations sur les
snapshots ayant ou n'ayant pas été mis à jour.
Lorsqu'un serveur procède à un rafraîchissement rapide d'un snapshot, il utilise les données du
snapshot log de la table maître pour régénérer le snapshot de manière plus efficace. Seuls les
changements effectués sur la table maître depuis le dernier rafraîchissement du snapshot en cours,
sont pris en compte. Oracle épure automatiquement du snapshot log toutes les données qui ne sont
plus utiles, en tenant compte de l'état de mise à jour de l'ensemble des snapshots de cette table
maître.
Rappelons que les snapshots log ne peuvent être utilisés avec les snapshots complexes, et qu'il n'y a
qu'un seul snapshot log par table maître quel que soit le nombre de ses snapshots.
Création d'un snapshot log
Pour créer un snapshot log, on exécute la requête suivante sur la base maître :
CREATE SNAPSHOT LOG ON nom_table_maître
Deux cas de figure se présentent pour les deux prochains rafraîchissements du snapshot :
Cas où la création du snapshot est antérieure à la création du snapshot log
Les rafraîchissements se feront à partir de la table maître depuis la création du snapshot jusqu'au
premier rafraîchissement suivant la création du snapshot log pour tenir compte des modifications
effectuées sur la table maître entre la date du dernier rafraîchissement et la date de création du
snapshot log. Ce n'est qu'à partir du deuxième rafraîchissement suivant la création du snapshot log,
que ce dernier sera utilisé.
Cas où la création du snapshot est postérieure à la création du snapshot log
Dans ce cas, le prochain rafraîchissement se fera à partir de la table maître. Les suivants se feront,
bien entendu à partir du snapshot log (cf. Fig. 1).
Page 11/17
Utilisation d'un snapshot log.
Exemple
Sur la base bd1 du serveur s1, on exécute la requête suivante :
CREATE SNAPSHOT LOG ON emp_ros ;
Voici les objets que Oracle crée :
Bd3
Bd1
I_SNAP$_EMP_ROS
INDEX
MLOG$_EMP
TABLE
SNAP$_EMP_ROS
TABLE
EMP
TABLE
EMP_ROS
VIEW
TLOG$_EMP
TRIGGER
MVIEW$_EMP_ROS
VIEW
7/3.1.7 Groupe de snapshots
Groupe de snapshots
Pour pouvoir rafraîchir plusieurs snapshots en même temps, il faut créer un groupe de snapshots
(Snapshot Refresh Group). L'exécution de ce groupe permet de rafraîchir chacun des snapshot le
composant avec la méthode avec laquelle le snapshot a été créé. Un groupe peut contenir des
snapshots de types différents.
Un groupe de snapshots permet de maintenir la cohérence des données entre plusieurs snapshots
ayant un lien de parenté.
Création d'un groupe de snapshots
La procédure MAKE du PACKAGE DBMS_REFRESH permet de créer un groupe de snapshots.
Page 12/17
Au moment de la création d'un read-only snapshot avec la commande CREATE SNAPSHOT, un
groupe de snapshots est automatiquement créé. Il porte le nom de ce snapshot et contient un seul
membre : ce snapshot.
Enlever un snapshot d'un groupe de snapshots
La procédure SUBSTRACT du PACKAGE DBMS_REFRESH permet d'enlever un snapshot d'un
groupe de snapshots ; ceci n'implique ni la suppression du snapshot ni la suppression du groupe de
snapshots.
Règles syntaxiques
Voici la syntaxe pour rafraîchir manuellement un groupe de snapshots existant :
EXECUTE DBMS_REFRESH.REFRESH(nom_groupe) ;
Et la syntaxe pour rafraîchir manuellement des snapshots appartenant à des groupes différents :
EXECUTE DBMS_SNAPSHOT.REFRESH(LIST nom_snapshot1, nom_snapshot2,.., METHOD
m1m2..) ;
m1, m2 .. représentent les lettres C pour COMPLETE et F pour FAST
Exemple
BEGIN
DBMS_REFRESH.SUBSTRACT (
NAME => 'ED_ROS',
LIST => 'ED_ROS')
DBMS_REFRESH.SUBSTRACT (
NAME => 'EMP_ROS',
LIST => 'EMP_ROS')
DBMS_REFRESH.MAKE (
NAME => 'GROUPE_ROS', /* NOM DU GROUPE
LIST => 'EMP_ROS, ED_ROS', /* LISTE DES SNAPSHOTS LE COMPOSANT
NEXT_DATE => SYSDATE,
INTERVAL => 'SYSDATE + 2/1440',
IMPLICIT_DESTROY => TRUE) ;
DBMS_REFRESH.REFRESH('GROUPE_ROS') ;
DBMS_SNAPSHOT.REFRESH(LIST => 'EMP_ROS,ED_ROS', METHOD => 'FC') ;
COMMIT ;
END ;
La clause IMPLICIT_DESTROY indique que le groupe sera implicitement détruit si plus aucun
snapshot n'en est membre.
Voici d'autres exemples d'intervalles de rafraîchissement :
Sysdate + 2
Exactement 2 jours après le dernier rafraîchissement
Sysdate + 1/24
Toutes les heures
7/3.2 Réplication symétrique ou évoluée
Page 13/17
7/3.2.1 Introduction
Contrairement à la réplication de base, les données répliquées par réplication évoluée sont
accessibles en lecture/écriture. Les mises à jour sont localement enregistrées et périodiquement
envoyées vers les autres sites.
La réplication symétrique est utile pour des applications de ce type :
Environnements déconnectés
Pour expliquer le concept des applications déconnectées, on va prendre l'exemple d'utilisateurs
mobiles équipés d'ordinateurs portatifs et ayant des besoins de mise à jour de données pendant leurs
déplacements. Ils ne peuvent se connecter à l'application centrale qu'une fois au bureau. C'est pour
ça que l'on parle d'applications déconnectées.
Site de secours
Comme dans n'importe quel environnement de réplication, la réplication évoluée peut servir à protéger
la disponibilité d'une base de données lors de pannes.
Distribution des charges d'application
La réplication évoluée est utile pour les applications nécessitant plusieurs points d'accès aux
informations de la base de données ; elle permet la répartition des charges sur des sites différents.
Transfert des informations
La réplication évoluée peut constituer un outil de transfert des informations. Par exemple, vous pouvez
vous servir de la réplication évoluée pour déplacer à intervalles réguliers des données d'une base de
données fortement sollicitée dans un entrepôt ou un dépôt de données.
7/3.2.2 Les différents types de réplication symétrique
Il y a deux types de configurations :


– Multi-master table replication ;
– Updatable snapshots.
Multi-master table replication
La réplication à plusieurs maîtres permet des réplications complètes de tables (full-table replication).
Oracle supporte la réplication de tables, index, synonymes, triggers, vues et packages. Oracle
supporte tant les changements au niveau des données (dml) qu'au niveau des schémas (ddl). La
seule manière de modifier le schéma d'une table répliquée est d'utiliser les procédures du package
DBMS_REPCAT et non plus la commande ALTER TABLE (cf. Fig. 1).
Page 14/17
Configuration à plusieurs maîtres.
La création d'un environnement répliqué commence par le choix du Master definition site parmi tous
les sites maîtres, la définition de tous les liens et l'attribution des privilèges nécessaires à
l'administrateur de réplication. Puis on crée un groupe d'objets répliqué maître au Master definition site
en utilisant la procédure DBMS_REPCAT.CREATE_MASTER_REGROUP.
Exemple
BEGIN
DBMS_REPCAT.CREATE_MASTER_REGROUP (GNAME <SPAN
ENT="8594;"> 'nom_du_groupe') ;
END ;
Ensuite, pour chaque objet devant faire partie du groupe, il faut l'ajouter au groupe en utilisant la
procédure CREATE_MASTER_REPOBJECT.
Exemple
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
SNAME <SPAN ENT="8594;"> 'nom_du_schema',
ONAME <SPAN ENT="8594;"> 'nom_de_l'objet',
TYPE <SPAN ENT="8594;"> 'type_de_l'objet',
USE_EXISTING_OBJECT <SPAN ENT="8594;"> TRUE,
COPY_ROWS <SPAN ENT="8594;"> TRUE,
GNAME <SPAN ENT="8594;"> 'nom_du_groupe') ;
END ;
Le paramètre USE_EXISTING_OBJECT TRUE permet à Oracle, lors de la réplication sur les autres
sites maîtres de l'objet nouvellement créé, de le créer s'il n'existe pas, sinon les deux objets doivent
être identiques. Pour une table, le paramètre COPY_ROWS TRUE permet de remplir la table
répliquée avec les données de la table du Master definition site.
Si des conflits de mise à jour sont possibles, il faut appeler les procédures permettant de les prendre
en charge.
Pour ajouter un site maître, on utilise la procédure DBMS_REPCAT.ADD_MASTER_DATABASE.
Page 15/17
Exemple
BEGIN
DBMS_REPCAT.ADD_MASTER_DATABASE (
GNAME <SPAN ENT="8594;"> 'nom_du_groupe',
MASTER <SPAN ENT="8594;"> 'nom_du_nouveau_site_maître',
USE_EXISTING_OBJECTS <SPAN ENT="8594;"> TRUE,
COPY_ROWS <SPAN ENT="8594;"> TRUE,
PROPAGATION_MODE <SPAN ENT="8594;"> 'asynchrone_ou_synchrone') ;
END ;
Pour planifier la propagation, on utilise la procédure DBMS_DEFER_SYS.SCHEDULE_EXECUTION.
On ne peut effectuer des mises à jour sur les objets répliqués tant que le schéma répliqué du Master
definition site est inactif ; il faut exécuter sur ce site (Master definition site) la procédure :
DBMS_REPCAT.RESUME_MASTER_ACTIVITY (nom_du_schéma).
Updatable snapshots
Comme un snapshot read-only, un updatable snapshots est une copie (complète ou partielle) d'une
table qui reflète un état récent de sa table maître. Néanmoins, un updatable snapshot ne peut être
complexe et ne peut être dérivé de plusieurs tables maîtres. Un updatable snapshot doit être un
snapshot simple.
Oracle reporte les modifications apportées à un updatable snapshot dans la table maître distante. Si
nécessaire, les modifications sont reportées en cascade aux autres sites maîtres (cf. Fig. 2).
Updatable snapshots.
Oracle régénère les updatable snapshots dans des groupes de régénération, qui sont identiques aux
read-only snapshots.
Page 16/17
Lorsqu'on crée un updatable snapshot, en plus des objets créés pour un read-only snapshot, deux
objets sont créés :


– Oracle crée une table appelée USLOG$_snapshot_name pour stocker le ROWID du tuple
mis à jour ainsi que le moment (Timestamp) de la mise à jour ;
– Oracle crée un trigger after row sur la table de base du snapshot appelé
USTRG$_snapshot_name pour insérer le ROWID des tuples modifiés ou effacés ainsi que le
moment de la mise à jour.
Page 17/17