Discussion :

[fab]

Bonjour,

J'ai déjà posté dans le forum SQL mais je n'ai pas eu de réponse claire. Le problème vient peut être de ma base.

J'ai une requete select assez importante. Je l'optimise et finit par avoir mes 1748 lignes en quelques secondes. Parfait.

Je veux insérer ce résultat dans une autre table avec un INSERT INTO () VALUES (SELECT...)

J'ai bien suivi les instructions d'optimisation préconisé : type de colonne identique et nommage des colonnes dans la 1ere partie du INSERT.

Malgré cela le temps d'insert est vraiment très long : plusieurs dizaines de minutes !

Pour info j'utilise des DB LINK.

Quel peut-être le problème ?

Merci

[chrifo]

Bonjour,
Vous faites peut-être le select sur l'instance distance (via /*+ DRIVING_SITE=<table> */ par exemple).
Lorsque vous passez en insert, Oracle exécute le select depuis l'instance locale, ce qui le plombe complètement. Je crois que ce pb est un bug référencé ...

[orafrance]

il ne faut pas utiliser VALUES si c'est par SELECT

Tu peux passer les indexes à USUSABLE et les rebuilder en fin d'insert, désactiver les contraintes et les triggers et utiliser le hint APPEND... tu peux aussi passer la table en NOLOGGING le temps de l'insert.

[fab]

Merci pour vos réponses.

Je ne met pas le VALUES, c'était pour expliquer le principe, désolé.

J'ai déjà lu pas mal de questions et papiers sur le sujet, j'ai bien essayé de désactiver les index, mettre le /*+ APPEND */, etc.. mais sans succès.

Pour le bug, l'explication me semble bien correspondre au problème. Je n'ai rien trouvé sur metalink d'oracle. J'ai peut-être mal cherché.
Avez vous plus d'info à me de donner ?

Merci encore

[chrifo]

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

[fab]

Ok, . Il n'y a apparemment pas de solution, Oracle ne semble pas vouloir traiter ce bug.

Tanpis, je contourne en passant par une procédure stockée, For (select...) loop insert... end loop;

C'est moins élégant mais cela marche rapidement.

[orafrance]

pense au bulk collect dans ce cas

[remi4444]

Si le select est un peu compliqué (impliquant plusieurs tables), l'optimiseur oracle a parfois la "bonne" idée de ramener toutes les lignes de certaines tables et de faire sa jointure en local.... ça se voit en éditant le plan d'exécution (plusieurs branches se terminant par "remote").

Explication:
- Si on fait un select avec toutes les tables faisant partie du meme db-link, oracle execute toutes les jointures sur le site distant et ramène le resultat.
- Si on fait des jointures entre des tables locale et distantes, ou entre plusieurs db-link différents alors l'obtimiseur choisi...
-> le gros défaut est que lorsque on fait un insert dans un table locale d'un select distant, oracle considère qu'il est dans le 2ieme cas, donc l'optimiseur choisi, et pas toujours bien...

J'y ai personellement passé des nuits blanches sur ce genre de saloperies...
La solution la plus stable (et préconisée par oracle si je me souviens bien) est de se débrouiller à faire une vue sur le site distant (celui du select) de manière à simplifier au maximum la requête pour n'arriver qu'a un simple truc du genre:

Code :

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

INSERT INTO TABLE_LOCALE SELECT * FROM VUE_DISTANTE@DB_LINK WHERE truc=machin .....

Si tu as fait ta procédure sur le site ou tu fais tes selects, c'est stable aussi.
De toutes manières, il ne faut pas perdre son energie à bricoler des insert/select compliqués à travers des db-link, car meme si ça a l'air d'etre rapide, on ne peux pas controler le taux d'utilisation du réseau et on n'est pas à l'abris d'un changement de plan d'exécution....