Très grosse stored procedure : temp tables ? alternative ?

Bonjour,

J'ai créé une très très grosse stored procedure, qui va chercher des données de plusieurs tables faisant chacune d'elles plusieurs millions de lignes, effectue beaucoup de transformations pour ensuite verser la table résultante dans une table finale indexée etc...

Telle que je l'ai créé, j'ai une multitude de tables temporaires intermédiaires (20 environ) que j'utilise pour extraire les données, les manipuler, les assembler etc...

Je créé un index pour chaque temp table, pour tenter d'accélérer les traitements. Aussi, je drop chaque table intermédiaire après avoir fini de l'utiliser.

Malheureusement, ma sp prend toujours des heures à tourner et j'essaie de l'optimiser.

J'ai lu à certains endroits que les tables temporaires étaient déconseillées à l'intérieur des sp... Est-ce vrai ? Avez-vous des alternatives intéressantes ?

Merci d'avance pour votre aide,

Sans voir le code de la proc et les tables en jeu... Impossible de vous aider !

A +

C'est bien ce que je craignais, impossible pour moi de vous montrer le proc ou les tables, pour des raisons assez évidentes de confidentialité. Je vous remercie quand même !

Bonjour,

en général, ce qui est confidentiel, ce sont les données. Le code en lui-même révèle-t-il des secrets de fabrication particuliers, comme une façon brevetée de créer une table temporaire ?

Haha jolie sarcasme ;)

Tous les champs utilisés ont des noms explicites, qui donneraient des informations sur le type d'entreprise pour laquelle je travaille, et le type de données qui sont exploitées, ce que je n'ai pas envie de rendre forcément publique.

Je pourrais bien sûr les communiquer par mp, mais c'est une très longue stored procedure (environ 30 select/insert je crois) et je ne suis pas sûr que quelqu'un soit assez motivé pour l'éplucher juste pour m'aider. J'espérais des propositions théoriques relativement génériques et simples à appliquer, je reconnais que c'était un peu utopiste de ma part.

Citation:

---

Envoyé par rudib

Bonjour,

en général, ce qui est confidentiel, ce sont les données. Le code en lui-même révèle-t-il des secrets de fabrication particuliers, comme une façon brevetée de créer une table temporaire ?

---

Tu sais bien que j'ai breveté le T_ .... finissant par un trigramme le tout en majuscule (dépôt légal n°7845842568426526 du 32 janvier 2874....

A +

Citation:

---

Envoyé par Suomi75

J'espérais des propositions théoriques relativement génériques et simples à appliquer, je reconnais que c'était un peu utopiste de ma part.

---

Il faut faire mieux. :aie:

Moi je peut vous donner 3 conseils génériques :
1) réduire le nombre de tables
2) réduire le nombre lignes
3) réduire le nombre de transformations
Avec cela, ça devrait le faire !!!!!

Testez, vous m'en direz des nouvelles....

A +

PS : je savait pas que la NSA avait migré aux pays bas....

Vous avez apparemment plus de temps à perdre que moi, à la prochaine :)

Bonjour,

Citation:

---

Envoyé par Suomi75

J'ai lu à certains endroits que les tables temporaires étaient déconseillées à l'intérieur des sp... Est-ce vrai ? Avez-vous des alternatives intéressantes ?

---

En effet, difficile de répondre à la question.
globalement, les tables temporaires sont à éviter, mais dans certaines situations, elles peuvent améliorer les temps de traitement globaux.
C'est par exemple le cas sur des requêtes complexes où l'optimiseur est pris en défaut. Mais dans ce cas, il faut comprendre la cause, car il peut simplement s'agir de statistiques insuffisantes, ou obsolètes.

Personnellement, je préfère faire sans table temporaire dans un premier temps, et ne les utiliser que pour résoudre des problèmes de performances pour lesquelles je n'ai pas de solution.

Du coup, je dirai que 20 table temporaires, ça semble vraiment excessif, surtout que vous semblez n'avoir qu'une seule table visée au final par une insertion.

vous pourriez essayer de les remplacer par des CTE, pour regrouper votre insertion en une seule requete et voir comment elle se comporte : cette modification est assez rapide à mettre en place.
Ensuite, si il n'y a pas d'amélioration, il faudra analyser ce qui bloque dans la requete et là.... ça pourra être beaucoup plus long.

bon courage

J'ai surtout l'impression, avec le peu d'éléments dont on dispose, qu'on essaye de faire faire par une SP ce qui devrait être fait par un traitement batch en plusieurs étapes

Sans dévoiler les secrets de l'entreprise, dans quel processus s'inscrit ce traitement ?
Quelle est sa fréquence d'exécution ?