Discussion :

[zinzineti]

Hello !
Depuis un certain temps je fais tout pour éviter d'utiliser les curseurs de façon explicite. Et j'en étais fier de ne pas utiliser les curseurs Et les arguments ne manquent pas pour justifier ce choix...Mais à ma grande déception le curseur explicite est plus performant que mes SELECT TOP1 ... DELETE. (Voir Démo)
A quelques heures de mon départ en vacances je voudrais partager avec vous ma réflexion qui est la suivante :
Quelle(s) solution(s) performante(s) pour éviter d'utiliser les curseurs ?

Merci d'avance

[SQLpro]

Un temps CPU est par nature TRES aléatoire. Il faudrait faire un "tir" de ces deux méthodes de nombreuses fois avec la concurrence (mutiples utilisateurs simultanés).
De plus vider tous les caches n'a aucun sens, car vous mesurer la capacité de votre disque à porter les données dans le cache cache... En principe toutes vos données devrait être systématiquement en cache (Cache hit ratio ne devant pas descendre en dessous de 95%).
Enfin, c'est avec un volume de données appréciables, c'est à dire sur un parcours de données dont la volumétrie est supérieure à la RAM que vous devez faire des mesures, car sinon, vous ne mesurer que la capacité de réponse du cache !

Bref, votre demo est totalement en dehors de ce qu'il faut faire pour mesurer les choses en production....

ENFIN, il n'y a pas UNE solution performante, mais plusieurs manière à adapter selon vos besoins : http://sqlpro.developpez.com/cours/s...r_avoidCursor/



A +

[zinzineti]

Merci SQLPro pour cette réponse, je viens d'enrégistrer une copie de ton article pour le lire posément. Mais avant de faire des tests dans un environnement idéal, comment justifier le fait que dans mon cas, le curseur est plus performant que ma requête ? Aussi il m'arrive de choisir entre 2 requêtes celle qui est la plus optimisée (ou d'optimiser des requêtes pour des collègues). Pour celà je me base sur le temps CPU et le nombre de page logiques lues. Comme indiqué dans mon billet (le lien ci-dessus)).
Comment obtenir des mesures fiables (durée d'exécution, nb de pages logiques,..) sans passer par le SQL Profiler ?
Merci d'avance

[SQLpro]

comment justifier le fait que dans mon cas, le curseur est plus performant que ma requête ?

Le faible volume des données est souvent à l'avantage de techniques sales. Dans le cas du curseur comparé à la requête, c'est souvent le temps de calcul du plan de requête qui est pénalisant....

Aussi il m'arrive de choisir entre 2 requêtes celle qui est la plus optimisée (ou d'optimiser des requêtes pour des collègues). Pour celà je me base sur le temps CPU et le nombre de page logiques lues. Comme indiqué dans mon billet (le lien ci-dessus)).
Comment obtenir des mesures fiables (durée d'exécution, nb de pages logiques,..) sans passer par le SQL Profiler ?

Il faut avoir un volume de données suffisamment proche de la réalité, et surtout consistant ! Sur un faible volume cela n'a pas de sens...
Après, il faut voir "en concurrence", c'est à dire dans la production réelle, car les verrous poser sur les ressources seront beaucoup plus pénalisant et pèserons sur le temps d'exec....

A +

A +

[zinzineti]

Le faible volume des données est souvent à l'avantage de techniques sales. Dans le cas du curseur comparé à la requête, c'est souvent le temps de calcul du plan de requête qui est pénalisant....



Il faut avoir un volume de données suffisamment proche de la réalité, et surtout consistant ! Sur un faible volume cela n'a pas de sens...
Après, il faut voir "en concurrence", c'est à dire dans la production réelle, car les verrous poser sur les ressources seront beaucoup plus pénalisant et pèserons sur le temps d'exec....

A +

A +

Ok merci.