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

Page 1/17
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 2/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 la transaction
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.
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. 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 :
o – une panne sur un site entraîne l'arrêt de tous les autres sites ;

Page 3/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 sous-
ensemble 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 4/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 5/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