Discussion :

[Macfurp]

Bonjour,

nous avons un traitement de reprise de données anormalement long pour lequel nous ne relevons aucune anomalie du coté mémoire, Cpu, etc... et pour lequel aucun problème n'est également constaté sur les accès qui passent sytématiquement par les clés primaires et autres index. Les volumétries traitées ne sont pas grandioses quelques dizaines de milliers de lignes insérées.
Je constate que toutes IO sql sont passées au travers de l'utilisation de procédures sp_cursoropen, sp_cursorfetch, aussi j'aimerai savoir si ce mode de fonctionnement est facteur d'aggravation des performances et éventuellement en quelle teneur...

Merci d'avance.

[elsuket]

Bonjour,

Effectivement l'utilisation de curseur est un facteur de lenteur, parce qu'on traite des ensembles de données ligne à ligne, ce qui est évidemment bien plus lent que de les traiter dans leur ensemble

L'utilisation de curseurs dans du code SQL est donc à proscrire.
Voici un article de SQLPro pour vous aider à les éviter.

@++

[Macfurp]

Merci pour la réponse, je n'ai malheureusement pas la main sur le developpement, je ne peux que constater les durées.

En complément peut-on également considérer en plus du fait de la problématique des DECLARE CURSOR que les EXEC de ce type mettent en oeuvre des appels de requètes de type dynamique encore plus couteuse que des requètes codées en "dur" dans une procédure stockée ?

[SQLpro]

En complément peut-on également considérer en plus du fait de la problématique des DECLARE CURSOR que les EXEC de ce type mettent en oeuvre des appels de requètes de type dynamique encore plus couteuse que des requètes codées en "dur" dans une procédure stockée ?

Vous ne pouvez pas l'en déduire.
Le seul moyen de le savoir est de lire le code applicatif pour s'en rendre compte.
Reste de toute façon que le SQL dynamique n'a que peu d'influence en général sur les performances.

En revanche l'utilisation des curseur est la pire des choses et est souvent synonymes d'incompétence en matière de développement "bases de données C/S". En effet aujourd'hui dans SQL Server 2005 qui admet les requêtes récursives, il n'y a plus aucune raison de continuer à utiliser des curseur pour traiter des données si ce n'est que l'ignorance des développeurs.

A +