Version imprimable
Bonjour
Qq'un peut me dire ce qui justifie qu'une requete select qui dure par exemple un 1/4 d'heure peut durer des heures lorsque je la tranforme en requete Insert ?
Je n'ai pas d'exemple à donner c'est juste une interrogation car j'ai déjà rencontré ce problème
Qu'entend tu par "transformer une requête select en requête insert" ?
Je precise l'environnement dans lequel je suis :
Oracle 10g
ce que j'entend par transformer en insert c'est simplement
J'ai ma requete
qui s'execute en un certain tempsCode:select ...FROM ...
et je transforme en insert
Code:
2
3
Moi, je n'ai jamais rencontré ce problème.Citation:
Envoyé par delphine93
Mais, tu est sur de fetcher toute les lignes quand tu fais ton select ? Tu es sur que tu n'as pas ajouté du code pour éviter les doublons dans l'insert ? Tu es sur que tu n'as pas des triggers de fou sur la table ou tu insert ? Ou une Virtual Private Database couteuse ?
Souvent ce sont les indexes, les contraintes associées à la table qui doivent être mis à jour / vérifées à chaque ligne d'insertion qui plombent les performances.
S'il n'y a qu'une PK, les performances demeurent rapides, mais si c'est une grosse table avec une dizaine d'index et de contraintes, ce sera très très très long.
Il peut aussi y avoir des triggers qui déclanchent d'autres actions.
Effectivement ça peut être une pisteCitation:
Envoyé par Waldar
Essaie de faire un tkprof pour voir les attentes
Comment vérifies-tu le temps d'exécution du select. Tu es en effet sûr qu'il te renvoie tout et pas seulement els X premières lignes comme ferait un TOAD?
Sinon, il faut en effet regarder si ta table dans laquelle tu insères à des indexes, si elle est dans le même tablespace que ta table source, le parallélisme, ...
A l'époque, la taille de tes extents pouvaient aussi jouer un rôle s'ils étaient trop petits. En 10G, on m'a toujours soutenu que ceci ne jouait plus du tout car c'était gérer tout seul. Je continue à avoir des doutes
Legendes urbaines Mythes Oracle ....Citation:
Envoyé par dragon74
Index doit etre separé ...
un seul extent, tres peu d'extent ...
Herité de Oracle 6 ?
http://www.idevelopment.info/data/Or...es/TBS_2.shtml
http://www.jlcomp.demon.co.uk/faq/table_frag.html
http://asktom.oracle.com/pls/asktom/...D:901906930328
Je pense que même en 10g, c'est pareil.Citation:
A l'époque, la taille de tes extents pouvaient aussi jouer un rôle s'ils étaient trop petits. En 10G, on m'a toujours soutenu que ceci ne jouait plus du tout car c'était gérer tout seul. Je continue à avoir des doutes
Le NEXT_EXTENT dit à Oracle combien d'espace supplémentaire, il doit allouer à la table (ou index) s'il a besoin d'espace.
L'allocation a forcément un coût.
On l'a vu sur un post l'année dernière d'un insert super long... Au final on a trouvé que le NEXT extent était de 10Ko et pour une insertion de 10 M lignes c'était l'enfer. Augmenter le next à résolu le problème.
En parlant des légendes urbaines, j'ai cherché sur le net l'histoire des reconstructions d'index. Et j'ai trouvé un pdf de Richard Foote : Index B-TRee - Rebuilding the Truth dans lequel il explique (dump à l'appui) que ça ne sert à rien.
J'ai des bases webtogo (base de synchro utilisateur) dans lesquelles les tailles d'index dépassent les tailles des tables associées.... Comme quoi.. la vérité est ailleurs ! :lol:
Je vais lire ce PDF, mais j'ai des doutes, voir des gros doutes, j'ai moi même écrit (modestement) un petit article ou j'essaye d'expliquer qui dans certains cas, cela ne sert à rien, il ne faut pas en faire une généralité !!
Et l'exemple que je donne montre (preuve à l'appui) que la reconstruction a été utile!
http://www.lao-dba.com/article-25594073.html
LAO.