Tout d'abord, sur le plan architectural, je me méfierais de toute conception impliquant l'extraction de données sur plusieurs liens de base de données. Je l'ai vu faire lorsque la source éventuelle est une ancienne version d'Oracle à laquelle la base de données cible ne peut pas se connecter directement, donc une base de données intermédiaire exécutant une version intermédiaire d'Oracle a été utilisée. C'est pourtant très rare en pratique.
Du point de vue de la performance, ce type d'approche est gravement problématique. Il y a, bien sûr, le problème que les données vont être envoyées deux fois sur le réseau. Mais plus inquiétant encore, vous prenez un problème difficile, en optimisant les instructions SQL distribuées et en le rendant presque insoluble. En gros, vous devez soit garantir que vous n'interrogerez jamais les données locales et les données distantes dans la même requête, soit vous devrez vivre avec les performances résultantes si Oracle décide d'un plan de requête stupide car l'ensemble d'outils restant pour vous permettre de optimiser ce type de requête est minime.
Cela étant dit, la base de données intermédiaire devrait avoir des synonymes ou des vues qui résument le lien de la base de données. Alors
Sur A :
- créer un lien de base de données vers B
Sur B :
- créer un lien de base de données vers C
- créer une
tablepour[email protected]
Sur A, vous pouvez alors
SELECT *
FROM [email protected]
