Discussion :

[delphine93]

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

[(Benoit)]

Qu'entend tu par "transformer une requête select en requête insert" ?

[delphine93]

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

Code :

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

 select ...FROM ...

qui s'execute en un certain temps
et je transforme en insert

Code :

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

1
2
3
 
insert into .... 
select ...FROM

[jmguiche]

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

Moi, je n'ai jamais rencontré ce problème.

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 ?

[Waldar]

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.

[scheu]

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.

Effectivement ça peut être une piste
Essaie de faire un tkprof pour voir les attentes

[dragon74]

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

[fatsora]

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 ....

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

[McM]

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

Je pense que même en 10g, c'est pareil.
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 !

[lallio]

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.