Bonjour,
 
Je suis en train de modifier une structure SQL, ses index et tout. En même temps je retouche les requêtes demandées par les applis. Si beaucoup d'entre vous ont assez de bouteille pour fonctionner "à l'instinct" moi je débute dans l'optimisation et je ne peux pas me fier à ce genre de chose.
 
J'aimerai savoir si il existe un moyen avec SQLServer pour qu'il me remonte le travail qu'il a du effectuer pour réaliser une requête; genre le nombre de micro-instruction (désolé pour mon langage d'électronicien) qu'il a du exécuter pour me faire remonter un résultat.
(j'ai du lire 4000 lignes une par une pour te trouver ton enregitrement car ya pas d'index)
 
Ainsi je peux juger dans mon coin la portée de mes modifs, quel type d'indexage est le plus performant, quelle requête est la plus judicieuse et fabriquer ainsi mon "instinct BDD" à partir de données quantifiables... Autre que le ridicule "ma page à mis 3,72 secondes pour s'afficher"
 
Merchi

avec 2005, je sais pas.
mais avec 2000, écrit ta requête dans sql query analyser.
là, dans "affichage" (je crois) tu peux lui demander notamment le plan d'exécution.

ceci dit, je te conseille grandement de faire tes tests en prod (ouais, c'est mal mais tant pis)
 
en effet, en local tu es rapidement victime du cache et autres, qui font qu'à la première execution, le résultat est faussé par le fait qu'il a dû décrouvrir la requête, mais les fois suivantes, faussé dansl'autre sens car la plupart des infos dont il a besoin sont déjà calculées et en mémoire.
 
donc si tu bosses sur une base qui est en cours d'utilisation intensive, tes résultats seront plus proche de la réalité

ok je passais par Entreprise Manager... En utilisateur que je suis j'ai pas encore l'habitude de jeter un oeil au reste.
 
Merci, je dois pouvoir trouver mon bonheur là dedans une fois que j'arrive à le faire marcher.
 
PS: sympa ton cours "topic" que j'ai consulté ici (pour les intéressés)
http://www.manga-torii.com/files/sgbd.pdf

oui et merci aussi pour ta remarque sur les caches.

pour moi l'optimisation sql, ca ne se repose que sur un seul indicateur : le temps d'execution.
il n'y pas d'astuces types pour faire de l'optimisation, tout dépend de la volumétrie attaquée pour chaque table, des indexes posés ou non et de la facon dont tu attaques les données.
un type d'écriture marchera très bien pour un cas mais pourrait être catastrophique dans un autre cas, il n'y pas vraiment de recette miracle.
maintenant tu as des outils pour comprendre comment fonctionne tes requêtes particulièrement le plan d'execution qui te donne les informations clés.

Je ne préconise pas non plus une écriture type. Je suis d'accord qu'à un rien près, deux requêtes peuvent voir leurs performances inversées.
 
Cependant, le plan d'execution est capital pour détecter les causes de ralentissement.
 
Tu peux retourner une requête pendant des heures, en utilisant des index à première vue corrects, et t'appercevoir que tu te palluche des row scan sur des index dans des traîtements nécessitant des routines très lentes.
 
Isoler à ce moment ce qu'à réellement effectué le moteur du SGBD est capital pour voir quelle partie de la requête pose problème.
 
Evidement, quand tu n'as qu'une requête simple avec 2 ou 3 tables liées tout simplement par leurs clés étrangères, tu peux t'en passer. Mais quand tu commences à avoir des requêtes avec jointures ouvertes multiples, des fonctions de regroupement sur plusieurs niveaux et 6 ou 7 niveaux d'imbrications de sous-requêtes, il devient vital de consulter ce plan, sous peine de passer à côter de grosses lenteurs quand bien même on vient de faire une optimisation de la mort qui tue pour une requête.
 
Sous Oracle par exemple, je n'ai pas les outils nécessaires au boulot pour voir le plan d'exécution. Il m'est arrivé une fois de passer derrière un collègue qui avait une requête qui mettait 4 heures à retourner un résultat. Pas glop.
Je bosse dessus deux jours, pour successivement atteindre 1 heure pour 15 minutes d'éxecution.
 
Content du résultat, je me dis qu'il n'y a plus moyen de faire mieux.
 
Pourtant, je décide de tester cette requête chez un autre client (même modèle des données, c'est bien pratique), sur un poste où j'avais accès au plan d'éxécution. Quand j'ai vu qu'il restait encore 4 full scan sur des tables monstrueuses, j'ai rebossé quelques heures sur le machin, et je suis tombé à 150 ms. Sans le plan d'exécution, il ne me serait même pas venu à l'esprit après la première phase d'optimisations que je pouvais encore gagner autant...

Oui oui, j'ai survolé les outils avant d'aller manger, j'ai accès à des informations vitales. Il me reste encore à apprendre à bien les interpréter, je ne comprend évidemment pas ce que signifient pas mal d'indicateurs.
 
Je vais me plonger pas mal dans l'interprétation du plan d'exécution...
 
Par exemple un cost de 600% sur une table, ce chiffre doit-il me faire frémir systématiquement, ou bien est-ce une valeur courante?
 
"temps coulé = 370368 ms"     qu'il me dit
....
m comme "micro" ou bien SQL ré-invente les minutes windows avec un temps qui n'a rien à voir avec notre dimension?

Ouais, j'ai jamais bien pigé comment le truc marche Les chiffres sont un peu n'importe quoi Concentre-toi plutôt sur les types de traitements effectués, le nombre de lignes traîtés par traîtement (un full scan sur un grand nombre de lignes, c'est toujours emmerdant) ainsi que la répartition des % sur l'ensemble des traîtements.
 
De plus, vérifie que tu prends le vrai plan d'exécution, pas l'estimé, parceque ça donne pas du tout les mêmes résultat
 
Et en fait, le % débile du final, ça doit correspondre à un ration par rapport à l'estimé, ou un truc du genre. Je me suis jamais penché sur la question.

- apparté: Mon explication des % sur le plan d'exécution -
Elle est appuyée sur les recherches que j'ai faite sur des bons bouquins de référence, les conclusions, elles, sont de mon cru. Etant donné que je met ca là pour aider les gens susceptibles de consulter ce post je vous engage à me contre-dire si je dis des anneries, ou à compléter le cas échéant.  
 
Donc le % visiblement (et ca prend tout son sens)
 
Au départ le plan d'exécution passe par un optimiseur de requête qui cherche la meilleure façon de s'y prendre. Pour se faire il estime le travail que va demander la chose pour les différentes manières d'arriver au résultat. (Ca c'est certain)
 
Il garde la valeur de cette charge de travail quand il a choisi celle qui lui semble la plus avantageuse.
Donc sur le plan d'exécution le pourcentage affiché sous les icônes est celui du pourcentage de la somme de travail que lui a demandé l'exécution de la-dite sous-tâche comparativement au temps total estimé.
 
Un 600% indique donc que mon petit SQL ne met pas ses stats à jour (car il se sert des stats de fragmentation de tables et d'index pour ses estimations). Ayant 2 sous-tâches à 600% cela veut sans doutes dire qu'il a fait une mauvaise estimation de la charge de boulot (il a eu quand même 12 fois plus de boulot qu'il le pensait), il y a des grandes chances qu'il se soit gauffré en choisissant la méthode...    
 
A celà 2 solutions...
-la barbare! (encore elle)    
Tu forces l'utilisation d'un index dans ta requête et/ou le respect de l'ordre des termes de ta requete. Tu te dis que cette solution imposée est la meilleure et le plan d'exécution arrête de te les casser avec des %, d'ailleurs tu arrêtes de lire le plan d'exécution, bim!  
Mais comme toute solution barbare qui se respecte, elle n'est pas la bonne (dommage...)
 
-la soft: commencer par remettre les stats à jours.
 
Notez que visiblement la solution barbare est adoptable de temps à autre lorsque l'on veut optimiser l'optimisateur de requête. En effet vous lui économisez des comparaisons que vous jugez inutiles. Même si c'était pas dit dans mon bouquin je pense que c'est conseillé seulement si vous êtes sûr de l'évolution de la chose... Donc déconseillé pour la plupart d'entre nous. (enfin au moins d'entre moi)

Ca rejoint donc ce que je pensais aussi : le % final est par rapport à ce qu'il avait prévu. Cependant, pour les stats des index pas à jour, ça m'étonne légèrement, étant donné que j'ai déjà remarqué ça sur des bases où aucune modif n'avait été effectuée depuis la dernière mise à jour des stats. Mais cela reste parfaitement possible comme explication cependant.