II.4. MISE AU POINT DES REQUETES DISTRIBUEES
Un serveur BD Oracle génère à partir
d'une requête distribuée, des requêtes distantes, qu'il
envoie aux noeuds distants pour exécution. Les noeuds exécutent
alors les requêtes et retournent les résultats au serveur local.
Un post-traitement est exécuté pour enfin retourner le
résultat à l'utilisateur ou à l'application.
Les stratégies décrites dans ce qui suit, sont
utilisées pour optimiser les requêtes.
I.5.1. COLLOCATED INLINE VIEWS
Le moyen le plus efficace d'optimiser une requête
consiste à réduire au maximum l'accès aux BDs distantes et
de ne rapatrier que les données requises. Pour ce, Oracle utilise des
«Collocated Inline Views», c'est à dire des vues de plusieurs
tables distantes et en ligne, afin de forcer les restrictions sur les sites
distants.
I.6. REPLICATION DES DONNEES
De toutes les étapes précédentes, nous ne
faisions que la préparation de l'environnement pour atterrir sur la
réplication proprement dite.
Afin de réduire la quantité de données
transmises sur le réseau, et améliorer par conséquent les
performances des requêtes, plusieurs options de réplication
peuvent être envisagées : la Commande Copy, le Snapshots et
les vues matérialisées.
I.6.1. COMMANDE COPY
Cette première option consiste à
répliquer régulièrement les données sur le serveur
local au moyen de la commande COPY de SQL*Plus.
I.6.2. SNAPSHOTS
Cette option utilise des snapshots pour répliquer les
données depuis une source maîtresse vers plusieurs cibles. Les
snapshots peuvent être en lecture seule (ang. read-only) ou mis à
jour (ang. Update able). Avant de créer un snapshot, il faut d'abord
créer un lien vers la base de données source.
Deux types de snapshots peuvent être crées :
simples et complexes. Un snapshot simple ne contient pas de clause distinct,
group by, connect by, de jointure multi-tables ou d'opérations set. Mais
l'autre en contient quand même.
I.6.3. VUES MATERIALISEES
Une vue matérialisée peut apporter plusieurs
avantages au niveau performances.
Selon la complexité de la requête, on peut la
remplir avec des changements incrémentiels, à l'aide du journal
de vues matérialisées (MATERIALIZED VIEW
LOG), au lieu de la recréer.
A l'inverse des snapshots, les vues
matérialisées peuvent être utilisées directement par
l'optimiseur, afin de modifier les chemins d'exécution des
requêtes. Pour ce, il faut disposer du privilège QUERY REWRITE
pour pouvoir réécrire la requête.
Une vue matérialisée crée une table
locale pour stocker les données, et une vue qui y accède.
Les vues matérialisées sont le moyen que nous
allons utiliser dans notre cas pour assurer la répartition de notre
base.
| 
