T-SQL - Optimisation des Cursor / Tables temp

Bonjour, voilà, j'ai réalisé un script qui fonctionne, mais utilisant des cursor imbriqués les temps de traitements sont excessivements longs.

Ma fonction renvoie une TABLE appelée @resultat.
J'ai essayé d'optimiser mais j'ai buté sur un problème : en fait il y a un bout de script qui remplie cette table temporaire @resultat, puis une autre portion va chercher des données et met à jour cette table temporaire. Le soucis c'est qu'un update récursif sur 700 000 lignes c'est très très lourd !

Je suis en train d'essayer une autre méthode qui consisterai en la création de plusieurs tables temporaires, puis un insert massif dans ma table @resultat à la fin en utilisant des jointures sur toutes mes tables temporaires.

Le soucis, c'est que lorsque j'essaye de faire un select sur une table temporaire @resultatTemp1 j'ai le message suivant :

Code:

---

La variable scalaire "@resultatTemp1" doit être déclarée.

---

Pourtant cette variable est bien déclarée !!!

Auriez-vous des tuyaux ?

Merci !

Bonjour,

Si vous êtes vraiment obligé de passer par une variable table + un curseur, ne vous étonnez pas des temps de traitement longs.
Essayez plutôt d'utiliser une vraie table, indexez la proprement et veillez à utiliser des requêtes purement ensemblistes.

C'est tout à fait possible dès SQL Server 2005, en utilisant des CTE, qui en outre vous permettent d'effectuer des traitements récursifs.

Notez que les tables temporaires (# et ##) et les variables tables sont persistées, comme toute table, dans la base de données TempDB, que le moteur de base de données utilise massivement pour bien d'autres traitements ... donc vous pourrissez vos performances par cette utilisation.

Enfin une différence entre les variables tables et les autres tables, c'est que sur les premières, SQL Server ne maintient aucune statistique.
Par conséquent, il est impossible pour le moteur de base de données de créer un bon plan de requête.
Si vous utilisez des tables temporaires (# et ##), le moteur de base de données maintient des statistiques, mais toujours dans TempDB ...

En revanche pour votre erreur, impossible d'aller plus loin sans votre code.

@++ ;)

Merci de votre réponse, j'ai essayé de passer par une procédure stocker et d'updater directement les tables réelles.
C'est un peu plus performant mais reste lourd ! J'ai optimisé à fond mes clauses where pour arriver à quelque chose d'acceptable. Il n'y a pas de miracle en fait 8-)

Citation:

---

J'ai optimisé à fond mes clauses where

---

C'est-à-dire ? Avez-vous utilisé des S-ARG ? Avez-vous indexé les colonnes qui sont dans la clause WHERE ?

@++ ;)

Oui c'est ce que j'ai utilisé ; et j'ai effectivement ajouté des index. Je ne vois plus quoi ajouter, mais au final j'ai du gagner 30 à 50% de temps ; en ne traitant que ce dont j'ai besoin (à l'aide des S-ARG) j'ai pu passer de 30 mintes à 50 secondes :aie:

Citation:

---

30 mintes à 50 secondes :aie:

---

Un gain non négligeable, tout de même :mouarf:

Pour info, voici une petite comparaison ;)

@++ ;)

Merci je vais aller potasser tout ça :ccool: