rendre transparent une migration d'un utilisateur sur base

J'ai deux utilisateurs sur la même base(USER1, USER2).
User2 à le droit de delete sur USER1.TABLE1
User1 dois aller sur une autre base.

question
Comment à travers des mécanismes de synonymes, liens bd... rendre cela transparent pour les applis?

Pour l'instant ce que j'ai pu faire de mieux

créer un USER2 miroir sur la deuxième base.
Lui donner le doirt de delete.
créeer un lien bd de USER2 vers USER2.

Je peux faire le delete:

Code:

---

1 2	delete from USER1.TABLE1@mon_lien WHERE MYID:=:1;

---

Mais je n'arrive pas à faire

Code:

---

1 2	delete from USER1.TABLE1 WHERE MYID:=:1;

---

Et si je crée un lien de User1 vers USER1, je peux tout rendre transparent (select) mais pas donner le droit à USER2 d'écrire sur une base distante!


connaissez-vous une solution?

pourquoi préciser le owner dans le FROM : USER2.TABLE1 doit pointer sur la USER.TABLE1 (en local) et USER1.TABLES1 pointe sur USER1.TABLE1@mon_lien.

USER est le schéma qui contient les tables en local :)

Bonjour Oracfrance,
Oui, c'est le cas deux que j'expliquai.
Cela marche très bien pour faire du select, mais comment permettre le delete,insert,update sur une base distante dans ce cas?

Si USER1 est le owner de la table dans mon_lien, il n'y a pas de problème, il peut tout faire :koi:

oui, mais je veux que ce soit USER2 qui fasse une opération DML sur user1 qui est sur une table distante!


Et ce que tu me propose ne me permet pas de lancer cette commande (simplifié évidement)

Code:

---

1 2 3 4 5 6

connect USER2/PASSWORD     delete from USER1.TABLE1 WHERE MYID:=:1;

---

si USER1 est sur une autre base!

Je peux faire un lien bd de USER2 vers USER1, mais dans ce cas USER2 aura le droit de tout faire et je ne le veux pas!

je ne comprends pas désolé :oops:

Si tu es connecté à USER2 tu veux pouvoir faire un DELETE des tables de USER1 distant alors que USER1 modifie bien ce qui est en local c'est ça ?

C'est le user de connection USER1 distant qui doit avoir les droits de DELETE sur les objets distant... tu veux pas plutôt coller le code avec l'erreur ?

c'est pas possible,

Il peux tout voir de manière transparente mais pas faire de dml.

Si je fait un grant, je récupère un ORA-02021:DDL operations are not allowed on a remote database

DDL pas DML ;)

Tu me parles de TRUNCATE, pas de DELETE si je ne m'abuse :ange:

Citation:

---

Envoyé par Fred_D

DDL pas DML ;)

Tu me parles de TRUNCATE, pas de DELETE si je ne m'abuse :ange:

---

non, je te parle de ddl.
C'est le grant qui bloque:

C'est quand je fais un grant delete on USER2 to TABLE1@mon_lien que je me prends le ORA-:02021

bien sûr, tu cherches à donner des droits sur une tables à un user qui n'existe pas dans la base de cette table :?

TABLE1@mon_lien :arrow: connection à USER1@mon_lien et accés à TABLE1

Si USERS1 à le droit DELETE sur TABLE1 dans mon_lien et USER2 à accés au DBLink, alors USERS2 a les droits DELETE puisqu'il se connect USER1 pour accéder à la table :?

reprenons depuis le départ, car clairement on se comprend mal:

au début, j'ai deux users (USER1 et USER2 ) sur une insatnce (BASE_B).
User2 fait des ddl sur user1.

Par exemple

Code:

---

1 2	delete from USER1.TABLE1 WHERE MYID:=:1;

---

maitentant, USER1 migre sur l'instance BASE_A.


deux solutions:

A créer un lien de USER1@BASE_B vers USER1@BASE_A
B créer un lien de USER2@BASE_B vers USER2@BASE_A.


A:

Code:

---

1 2 3 4 5 6

connect USER1/password@BASE_B   create dblink LIEN_A connect to USER1 using BASE_A   create synonym table1 for table1@BASE_A

---

USER1@BASE_B peux maitenant faire ce qu'il veux sur USER1@BASE_A.
Et tout est transparent pour tout le monde.

User2@BASE_B peux lire de manière transparente surr la base a.

ex:

Code:

---

1 2 3 4 5

connect USER2/password@BASE_B   select * from USER1@TABLE1

---

ramène bien les donnés de la base A.

Par contre, comment permettre à USER2@BASE_B de faire un DDL sur USER1.table1@BASE_A dans cette configuration??



B:

Code:

---

1 2 3 4 5 6 7 8 9 10

connect USER1@BASE_A   grant delete on TABLE1 to USER2.   connect USER2@BASE_B   create dblink LIEN_B connect to USER2 using BASE_A   delete from USER1.TABLE1@BASE_A WHERE MYID:=:1;

---

Ok, cela marche, mais je ne peux pas créer dans ce cas la de synonyme.

Je rappelle que je dois rendre cette migration invisible pour les applis(enfin si c'est possible évidement!).

Code:

---

1 2 3 4 5

connect USER1/password@BASE_B   create dblink LIEN_A connect to USER1 using BASE_A   create synonym table1 for table1@BASE_A

---

Donc LIEN_A appartient à USER1, or c'est USER2 qui l'utilise... y'aurait pas un problème ? :koi:

Ton cas A n'est pas clair... fait la même descritpion avec TOUTES les commandes à la suite et l'erreur provoquée STP... désolé si j'suis un peu lourd :oops:

Citation:

---

Envoyé par Fred_D

Code:

---

1 2 3 4 5

connect USER1/password@BASE_B   create dblink LIEN_A connect to USER1 using BASE_A   create synonym table1 for table1@BASE_A

---

Donc LIEN_A appartient à USER1, or c'est USER2 qui l'utilise... y'aurait pas un problème ? :koi:

Ton cas A n'est pas clair... fait la même descritpion avec TOUTES les commandes à la suite et l'erreur provoquée STP... désolé si j'suis un peu lourd :oops:

---

non, tu n'es pas lourd du tout, tu as même raison, je me suis tromprée dans le cas A. USER2 ne peux pas voir les tables de USER1@BASE_A.


Donc mantenant que l'on se comprends bien, pense tu qu'il y a une solution à mon problème?

Il faut poursuivre sur le cas B?
Dans le pire des cas, Je pense faire cela, créer un dblink de base_B sur BASE_B, faire changer les codes pour avoir partout

Code:

---

1 2	delete from USER1.TABLE1@BASE_A WHERE MYID:=:1;

---

Puis lors de la migration, changer le lien vers base_A...

bah non, tu crées le DB Link sur USER2 et c'est réglé en principe non ?

tu veux dire le dblink de user2@base_b vers user1@base_a?


Si c'est cela, je ne suis pas d'accord.
En effet, je ne veux pas que USER2 puisse faire ce qu'il veux sur USER1. Seulement quelques opération ddl que je controle.

Et en plsu, on a toujours le même problème de rendre les opérations transparentes. Ce ne seraot pas possible dans cette configuration si on 'oublie' les problèmes de sécurité.


Sinon, on se comprend mal :arf:

ne te manque-t-il simplement pas :

Code:

---

1 2 3

connect USER1/password@BASE_B grant delete on TABLE1 to USER2.

---

dans le cas A ?

Citation:

---

Envoyé par Fred_D

ne te manque-t-il simplement pas :

Code:

---

1 2 3

connect USER1/password@BASE_B grant delete on TABLE1 to USER2.

---

dans le cas A ?

---

c'est ce que j'expliquai au début.
Ce n'est pas possible car la table 1 est sur la base A.

Donc tu dois faire

Code:

---

1 2	grant delete on TABLE1@LIEN_A to USER2.

---

et tu te prends une ORA-02021!

Non, tu dois te connecter à LIEN_A avec le propriétaire de TABLE1 (USER1 si je ne m'abuse) et granter delete à USER2...

Citation:

---

Envoyé par Fred_D

Non, tu dois te connecter à LIEN_A avec le propriétaire de TABLE1 (USER1 si je ne m'abuse) et granter delete à USER2...

---

impossible car les deux users ne sont pas sur la même base

mais si :scarymov:

Citation:

---

au début, j'ai deux users (USER1 et USER2 ) sur une insatnce (BASE_B).
User2 fait des ddl sur user1.

au début, j'ai deux users (USER1 et USER2 ) sur une insatnce (BASE_B).
User2 fait des ddl sur user1.

---

donc user2 accéde aux tables via un dblink qui se connecte USER1@BASE_A.
le problème dans ce cas c'est que user2 peut tout faire. Donc tu crées un user USER2 sur BASE_A qui a juste les droits de DELETE sur USER1.TABLE1 de la même base et dans BASE_B tu crées un dblink qui se connecte USER2@BASE_A. Comme le USER2 qui sert à se connecter a les droits DELETE tout est OK.

C'est clair maintenant ?

Si je reprends B :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

connect USER1@BASE_A CREATE USER2 IDENTIFIED BY USER2;   grant delete on TABLE1 to USER2;   connect USER2@BASE_B   create dblink LIEN_B connect to USER2 using BASE_A   CREATE SYNONYM table1 FOR USER1.TABLE1@BASE_A;   delete from table1 WHERE MYID:=:1;

---

[/code]