Discussion :

[guigouz]

Bonjour à tous!

Je souhaiterais mettre en œuvre une base de données Oracle contenant une table partitionnée, et dont chaque partition serait distribuée sur des instances distinctes.

Un exemple simple : une table CLIENT dont le champ ville contient deux valeurs possibles : 'Marseille' ou 'Paris'.
Physiquement : on a une instance Oracle à Marseille et une autre à Paris.
Logiquement : on a une seule table CLIENT qui serait une sortie de vue sur les deux partitions, nommées CLIENT_M et CLIENT_P.
Objectif : effectuer des requêtes de manières transparente (par exemple, lors d'un insert, ne pas préciser la partition de destination) tout en ayant la possibilité de faire des select sur une seule partition (les clients de la partition à Marseille, pour ne pas consulter inutilement la partition à Paris).

Après avoir bien parsé la doc Oracle et divers forum, état des lieux de ce qui est possible :
- le partitionnement par valeur est très bien intégré dans Oracle. J'ai pu créer une table CLIENT avec deux partitions, mais dans une même base. Les insert/update/delete se font de manière transparente (sans spécifier explicitement la partition de destination), et les select des manières suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM CLIENT;

Ou, si l'on ne souhaite interroger qu'une partition :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM CLIENT PARTITION(CLIENT_M);

Pour ce qui est de la distribution, là aussi y'a plein de doc qui explique comment faire des liens (database links) d'une base vers une autre.

Par exemple, je peux créer deux tables (CLIENT_M et CLIENT_P) dans deux instances et y accéder assez simplement lors des requêtes CRUD via les liens.
Par contre ici, tout doit être géré manuellement côté applicatif (enfin, si j'ai bien compris), ce qui implique par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM CLIENT@PARIS_LINK;

Et surtout :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

INSERT INTO CLIENT@PARIS_LINK VALUES(...);

Par conséquent, je voudrais savoir si une personne qui s'y connaît plus que moi en DBA Oracle a déjà rencontré ce problème... où une piste pour contourner ce problème.

Un moyen de "faker" le SGBD serait (je n'ai pas encore essayé) de faire une view dans chaque instance qui référencerait le contenu de la table locale et de la table distante.

Pour les insert, update et delete, à l'aide de triggers on doit pouvoir intercepter les requêtes et les "orienter".
C'est hyper crado je sais mais c'est juste pour savoir si c'est possible en théorie!

Désolé pour le message un peu long, j'espère que c'était clair au moins
Merci par avance pour les éventuelles réponses.

Guigouz

[Ahmed AANGOUR]

Bonjour,

Pourquoi voulez-vous vous connecter à ces 2 bases? Est-ce à des fins de reporting?

[guigouz]

Pardon pour cette réponse tardive je pensais ne plus avoir de réponses.

En fait, je suis actuellement à la fac un cours sur les bases de données distribuées.
Après avoir étudié les principaux concepts (fragmentation, réplication et localisation) ainsi qu'un formalisme de modélisation, on nous a demandé de choisir un SGBD et de mettre en œuvre un projet de distribution de données.
Si on est amené à rencontrer un problème (limitation du SGBD), on doit trouver des solutions de contournement même si elles ne sont pas très esthétiques.

Pour ce qui est de la réplication, Oracle est blindé.

J'ai choisi de faire un mix entre fragmentation (que l'on peut associer à du partitioning dans le langage Oracle) et localisation (répartition d'une même base de données sur plusieurs sites - géographiquement parlant - tout en offrant une abstraction sur l'accès et la manipulation des données).

Donner un accès transparent à des tables distantes : ça se fait très bien avec les database links et des synonymes.
Faire du partitionnement en fonction de règles prédéterminées : ça aussi c'est facile !

Mais dans ce cas je voudrais que chaque fragment (= partition) soit distant l'un de l'autre et représente une part des données d'une vue globale... et là ça se corse forcément.
D'où l'exemple des clients dans deux fragments, ceux de Marseille dans un fragment physiquement à Marseille et ceux de Paris dans un fragment physiquement à Paris.

Si je fais un select sur la table "logique" CLIENT depuis Paris, je demande à la base de Marseille de me renvoyer les données de son fragment.
Mais si je fais un select sur CLIENT_P depuis paris, je n'embête pas le SGBD de Marseille.

Je sais pas si c'est bien clair, je ne dis pas que c'est utile hein mais j'essaye de le faire et j'ai trouvé une solution pas trop crados finalement... A voir si ça passera c'est pour mon master, j'aimerais bien!

Voici un schéma rapide que je souhaite faire (je suis en Erasmus à Madrid d'où l'espagnol). La vue "customer" permet de voir à chaque fois les données de sa table locale et les données de la table distante, c'est tout con!


Enfin bref, merci pour ta réponse, si tu as des éléments à cotés desquels je suis passé n'hésite pas à me le dire!

Guigouz