Discussion :

[argoet]

Bonjour à tous
Environnement HP-UX 11 : Oracle 10g (Base B) et Oracle 9i (Base A)

Est il possible dans une boucle PL/SQL :

Code :

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

1
2
- de faire une requete dans une base A (Oracle 10g) sur un serveur A
- en fonction du resultat mettre à jour une base B (Oracle 9i) sur le serveur B

Code :

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

1
2
Contrainte technique : l'utilisation d'un DATABASE-LINK est interdit 
(Notre protocole de sécurité nous impose cela dans cette configuration)

Quelle sont les autres moyen qui sont à disposition pour effectuer cette manipulation de donnée entre 2 bases Oracle ?

Merci de votre Aide

[dgi77]

J'ai eu le même problème que toi chez plusieurs clients, toujours pour la même raison : SECURITE !
Mais je ne vois pas pourquoi ?
Il suffirait qu'ils nous limitent en SELECT les bases sensibles...

En tous cas, je n'ai pas trouvé de solution aussi pratique que les DBLINK.
A chaque fois, on doit exporter et réimporter les données d'une manière ou d'une autre (spool puis loader, exp/imp Oracle, ETL), ce qui exige en plus de faire un transfert de fichiers entre les 2 serveurs.

Donc, je crains qu'il ne te reste que tes yeux pour pleurer.
A moins que quelqu'un ait une solution lumineuse... Je suis également preneur.

[laurentschneider]

spool + ftp + sqlloader ?

[dgi77]

Oui, dès l'instant où on s'interdit d'utiliser les DBLINK, je ne vois pas mieux...
Mais bon, j'attends la suite, car à Laurent Schneider, rien d'impossible...

[laurentschneider]

dans un projet il y a fort longtemps j'avais récupérer le tablespace concerné depuis le backup.

http://download.oracle.com/docs/cd/B...b.htm#CACJAEFH

(avec Oracle8i c'était un plus complexe mais exactement le même principe)

Ensuite tu peux faire ta requête localement et tu n'as pas accédé à la prod (seulement au backup, et la sécurité du backup, tout le monde s'en fout )

Bon week-end
Laurent

[dgi77]

C'est vrai que c'est une solution, mais c'est également beaucoup plus lourd que si on avait un DBLINK.
De plus, grâce à un DBLINK, tu peux filtrer sur les enregistrements qui t'intéressent avant de les ramener en local. Là tu ramènes toute la table (ou toutes les tables) du tablespace.

[laurentschneider]

dans ce cas il faut convaincre ton chef que le "protocole de sécurité" est ringard et que le database link se justifie

[sygale]

Dans le même esprit que laurentschneider.

Tu peux
- écrire un fichier
- transférer ce fichier sur le serveur B
- et faire pointer une table externe sur le fichier
- et faire les updates avec comme référence la table externe

Mais toutes les solutions seront moins performante d'un dblink

[Bruno2r]

Salut, je rejoins totalement nos amis : Y'a pas mieux que les dblinks
Mais si la contrainte de sécurité est inaliénable ...
Peut-être peux tu ruser ...

Exemple avec Business Objects
Une requête BO (en sql à la carte) pointant sur A
Une connection ODBC sur B
Export des données BO vers B (Crée la table)
SQL dans B

Même démarche avec une base Access ...
Table liée, et update

Ben quoi ? C'est pas du dblink !

L'avantage par exemple avec le rapport BO c'est que tu peux automatiser en VB l'export à chaque refresh (lui même automatisable)