INSERT INTO SELECT + DBLINK 9i/10g

Bonjour,

J'ai 2 BDD :
- BDD9i est une 9i
- BDD10g est une 10g
je souhaite inserer des records issus d'une requete de ma BDD9i vers une table de ma BDD10g

Quand je fais un

INSERT INTO matableremote@BDD10g
SELECT t1.champ1,t2.champ1,t3.champ1
FROM matable1 t1, matable2 t2, matable3 t3
avec tout plein de where....

Il met environ 2 minutes pour copier 15 records...
Et il ne me rends jamais la main avec 50000 records.

Si je passe par une table temporaire avec un
create matabletemp as
SELECT t1.champ1,t2.champ1,t3.champ1
FROM matable1 t1, matable2 t2, matable3 t3
avec tout plein de where....

il met 20 secondes pour creer la table de 50000 records
et le
INSERT INTO matableremote@BDD10g
SELECT champ1,champ2,champ3 from matabletemp
met 15 secondes ... 8O

Une idée ???

oui, il fait des jointures à travers le réseau...

La règle est la suivante:

- quand toutes les tables d'une requête sont issues du même dblink, oracle exécute entièrement sa requête sur le site distant

- quand la requête concerne des tables sur plusieurs db_links différents ou sur un mélange db_link / local, oracle choisi en fonction de critères mystèrieux (enfin pour moi en tout cas)

Quand tu fait un :

Code:

---

1 2 3

insert into table_distante@DLINK select machin, bidule from table_locale1, table_locale2 etc...

---

Il considère qu'il est dans le 2ieme cas donc il peut choisir de faire certaines opérations en local et certaines en distant. tu peux le voir en éditant le plan d'exécution.

Par exemple imagine qu'il doivent faire une jointure par HASH entre 2 accès complets sur 2 tables locale puis insérer le tout sur une table distante. Tu vas t'attendre à ce qu'il fasse sa cuisine en local et qui insère le tout à la fin.... Et bien parfois, il choisi de balancer le contenu complet de tes 2 tables dans ton db_link et faire l'opération de jointure sur la base distante!

Ceci à comme double effet:
- de rendre la procédure tres longue
- de saturer complètement le réseau

Théoriquement, en passant les stats sur les 2 bases, il est censé choisir le bon plan, mais dans la pratique, il se plante trés souvent. C'est pourquoi, il faut éviter de faire des requête avec jointures compliquées (meme avec jointure tout court...). La méthode la plus stable est de faire une vue de manière à ce que ta requête devienne un truc du genre:

Code:

---

1 2 3 4 5

insert into table_distante@DBLING select machin, bidule, etc... from vue_locale where truc = bazard and etc...

---

Merci pour ta reponse rapide...

Je comprends bien ce que tu dis... seulement meme en passant par une vue le traitement est tout aussi long.

alors que le select * de cette vue est super rapide...

La seule soluce (pour moi...) pour l'instant c'est une table temporaire a defaut de trouver mieux :?
Je continue a chercher de mon coté...

@+

Citation:

---

Envoyé par dbaenbois

meme en passant par une vue le traitement est tout aussi long.

---

tiens... moi j'avais été confronté au problème en 8i, et cette méthode fonctionnait bien (elle était même préconisée sur le metalink si je me souviens bien...)

Est-ce que tu as essayer d'utiliser le hint /*+ MERGE (la_vue) */ ?

Citation:

---

Envoyé par dbaenbois

alors que le select * de cette vue est super rapide...

---

c'est rapide sur l'ensemble ou c'est toad (ou autre outil ne fetchant que le début du curseur) qui te renvoi les premières lignes rapidement ?

... pas mieux avec le hint /*+ MERGE (la_vue) */ (merci quand meme :D )

J'utilise sqlplus sous linux...
Et quand je dis c'est rapide, l'affichage de mes lignes est instantané....

Citation:

---

pas mieux avec le hint /*+ MERGE (la_vue) */

---

:koi:

euh... quand je dit "la_vue" il faut remplacer par le nom ou l'alias de la vue que tu utilises, on est bien d'accord ? :)

Il faudrait éditer le plan d'exécution pour en avoir le coeur net, il va y avoir l'étiquette "REMOTE" à chaque fois qu'il décide d'envoyer un flux dans le dblink.

Citation:

---

euh... quand je dit "la_vue" il faut remplacer par le nom ou l'alias de la vue que tu utilises, on est bien d'accord ?

---

:mrgreen: Mort de rire !!! :mrgreen:

Effectivement je met bien le nom de ma vue...

Dans mon plan d'execution j'ai bien des SERIAL_FROM_REMOTE ...

Dans ta vue, tu n'a que des tables en local ou tu as d'autres db_link ?

j'ai un autre dblink... sur une 3eme BDD en fait... en 9i celle la...
c grave Doc ?:(

Salut,
Selection rapide, insertion plombée :
A tout hasard, il ne s'agirait pas du bug 2262861 ?

http://www.developpez.net/forums/sho...d.php?t=170051

Ca m'en a tout l'air....

En tous cas ... Merci... Merci à tous !

Reactivité, rapidité, efficacité... a bientôt 8-)

Citation:

---

Envoyé par dbaenbois

j'ai un autre dblink... sur une 3eme BDD en fait... en 9i celle la...
c grave Doc ?:(

---

oui!! :aie:

Déja qu'avec 2 bases l'optimiseur se prend facilement les pieds dans le tapis, alors avec 3, j'ose pas imaginer le massacre... :aie: En fait il doit s'amuser à faire des jointures sur ton 3ieme site....

Donc soit tu tente de continuer la méthode en faisant une vue sur ton 3ieme site regroupant toute les tables concernées, soit tu garde ta methode en passant par une table temporaire intermédiaire. Personnellement, j'ai tellement passé de temps à tenter d'optimiser ce genre de requête distribuée que depuis j'ai développé une alergie et je simplifie au maximum tout ce qui passe par un db_link.

Citation:

---

Envoyé par chrifo

Salut,
Selection rapide, insertion plombée :
A tout hasard, il ne s'agirait pas du bug 2262861 ?

http://www.developpez.net/forums/sho...d.php?t=170051

---

Je pense pas que ce soit exactement ça, mais y'a un rapport, c'est d'ailleurs surement en consultant cette note que j'ai découvert la methode des vues...

Citation:

---

Envoyé par remi4444

c'est d'ailleurs surement en consultant cette note que j'ai découvert la methode des vues...

---

Oui c'est vrai que les vues c'est LA solution :D

Ca se complique quand on ne peux pas créer d'objet sur l'instance distante ... dans ces cas là on est forcé d'imaginer des méthodes à base de curseurs et de boucles d'insertion :fou: