Version imprimable
Bonjour,
Dans SQL Server 2005, l'affichage du plan d'exécution graphique est généré par l'envoi au serveur d'un SET STATISTICS XML ON
seulement faut il le faire une fois pour toute sur la connexion OU devant chaque requêtes ,
ex:
De plus il est affiché où?Code:
2
Merci à l'avance
le plan d'affiche dans la grille de SSMS en bas après le résultat de la (les) requête(s)Code:
2
3
4
5
6
7
8
9
Bonjour,
C'est pour la session, et cela produit le même effet que de cliquer sur le petit bouton correspondant, dans la barre d'outils ;)Citation:
seulement faut il le faire une fois pour toute sur la connexion OU devant chaque requêtes
@++ ;)
Merci, j'ai bien affichage de du plan d'exécution estimé quand je sélectionne toute ma requête et fait clic droit afficher le plan d'exécution estimé
mais si j'encapsule ma requête avec
SET STATISTICS XML ON
et
SET STATISTICS XML OFF
quand j'exécute la requête, je n'ai plus affichage du plan d'exécution, en tout cas à l'endroit où il s'affiche avec le clic droit :cry:
De plus j'ai vu que sur clic droit il y avait "inclure le plan d'exécution réel", j'ai cliqué dessus et exécuté la requête mais pareille ne voie rien :cry:
appuie sur la touche F5 de ton clavierCitation:
Envoyé par bibouilles
ça marche :ccool:
je ne veut pas paraitre lourd mais sauriez vous ce qu'est vraiment la différence avec le plan d'exécution réel et comment l’obtenir svp?
Un peu de lecture ne jamais du mal ;)
SET STATISTICS XML
Plans d'exécution
Si tu as des questions après n'hésite pas ;)
Si vous voulez aller plus loin avec les plans d'exécution, il existe deux bons ouvrages sur le sujet :
- Inside the SQL Server Query Optimizer, de Benjamin Nevarez, qui vient de sortir en PDF
- SQL Server Execution Plans, que l'on trouve également en PDF
Les deux ouvrages expliquent très clairement comment lire les plans et les interpréter, ce qui n'est malheureusement pas le cas de la documentation de SQL Server qui est assez cryptique à ce sujet, lorsque l'on aborde les icônes du plan d'exécution graphique.
C'est une bonne base, l'expérience vous apprendra le reste.
Je vous recommande également l'excellent SQL Sentry Plan Explorer (téléchargement en haut et à droite, n'oubliez pas le plugin SQL Server Management Studio(SSMS)), qui :
- rend la lecture des plans d'exécution plus simple que ce que propose SSMS
- montre parfois des choses que ne montre pas SSMS
- montre avec quelles valeurs le plan a été généré
- permet de voir avec facilité s'il s'agit d'un problème d'estimations des cardinalités
- ...
Bref depuis que je l'ai téléchargé, je ne regarde plus les plans dans SSMS : un petit clic-droit dans le plan > View in SQL Sentry Plan Explorer ;)
Et il est gratuit !
@++ ;)
Les plans de requête sont mis en cache de façon a ce que si une requête similaire arrive (aux valeurs près), alors on reprend le même plan de requête.Citation:
Envoyé par bibouilles
Cependant les bases étant "vivantes", ce qui a été fait à un moment est susceptible de ne pas être le même quelques instants après.
La différence peut être :
- une augmentation ou diminution du volume des données
- une distribution différentes des données
- une valeur dans la requête radicalement différente
- un paramétrage de session/base/serveur différent
Tous ces éléments sont susceptible d'invalidé le plan estimé et donc d'entraîner un recalcul du plan de requête générant un plan différent au moment de l'exécution.
Pour estimer tout cela, SQL Server se sert de statistiques de distribution des données, ainsi que de statistiques sur les mises à jour des tables (INSERT + UPDATE + DELETE).
Tout cela est le travail de l'optimiseur...
A +
Qui doit cependant parfois être aidé d'un DBA, notamment :Citation:
Tout cela est le travail de l'optimiseur...
- pour la gestion des statistiques, dont il est parfois nécessaires de forcer la mise à jour
- pour la reconstruction des index, qui au passage met à jour les statistiques relatives à l'index
- plus rarement, ajouter des indicateurs de table, de requête ou d'index
@++ ;)
Merci bien,
une fois avoir expérienté les outils de MS sur le plan d'exécution:
j'ai installé SQL Sentry Plan Explorer (64 bit car suit sur seven 64 bit) et le pluggin pour MSSMS, (j'ai arrêté la base et MSSMS avant)
mais il ne me semble avoir rien de nouveau, en cliquant droit après avoir sélectionné la requête , ni même une fois avoir choisit d'exécuter le plan ou inclus le plan réel alors que je devrait avoir une proposition du genre "View with SQL Sentry Plan Explorer" dans le menu contextuel.:cry:
es-ce normale? que puis-je faire d'autre?
C'est inutile, dans tous les cas (pour votre problème ou n'importe quel autre) parce que vous supprimez dans ce cas tous les caches (de données et de procédure) + les données heuristiques collectées par SQL Server ...Citation:
j'ai arrêté la base et MSSMS avant
Il faut redémarrer SQL Server Management Studio, c'est tout.
Dans SSMS, cliquez sur le bouton Inclure de plan d'exécution réel, puis exécutez la requête : un onglet Plan d'exécution s'affiche : c'est dans celui-ci qu'il faut faire un clic-droit sur une zone vierge, pour obtenir l'option View in SQL Sentry Plan Explorer .Citation:
mais il ne me semble avoir rien de nouveau, en cliquant droit après avoir sélectionné la requête , ni même une fois avoir choisit d'exécuter le plan ou inclus le plan réel alors que je devrait avoir une proposition du genre "View with SQL Sentry Plan Explorer" dans le menu contextuel.
es-ce normale? que puis-je faire d'autre?
@++ ;)
Super ça marche:ccool:
Petite question au passage suis-je mieux de travailler avec le plan d’exécution réel que celui estimé?
Même quand ma base est quasiment vide avec personne d'autres dessus?:roll:
Vous pouvez travailler avec le plan d'exécution estimé, mais comme vous le disait SQLPro, celui-ci peut changer au moment de l'exécution de la requête, souvent en conséquences des modifications de données, de leur volume et des paramètres passés à la requête (s'il y en a).Citation:
Petite question au passage suis-je mieux de travailler avec le plan d’exécution réel que celui estimé?
Le plan généré est compilé avec les valeurs des paramètres au moment de l'appel, et peuvent entraîner la génération d'un plan qui ne conviendra pas à la plupart des autres appels, et dans ce cas-là il faut recompiler la requête ou bien forcer le recalcul des statistiques.
Le plan d'exécution réel vous permet de savoir ce qui s'est vraiment passé au moment de l'exécution, et révèle en outre les problèmes d'estimation de cardinalités : à la génération du plan, SQL Server a estimé, à l'aide des statistiques de colonne, qu'il y aurait un certain de nombre de lignes retournés par chaque prédicat.
Si les statistiques ne sont pas maintenues correctement, ou bien que votre requête utilise une variable de type TABLE, c'est souvent ce qui se produit.
En effet dans le 2e cas, SQL Server ne maintenant pas de statistiques sur de telles tables, il estimera toujours qu'il n'existe qu'une seule ligne dans celles-ci ... Sauf si vous faites suivre votre requête de l'indicateur OPTION (RECOMPILE) : à ce moment là SQL Server recalculera le plan de requête à chaque exécution, mais cela engendre un coût CPU.
Si la requête est exécutée très fréquemment, cela crée donc une pression CPU artificielle.
Cela n'a en principe aucune incidence sur la génération du plan de requête.Citation:
Même quand ma base est quasiment vide avec personne d'autres dessus? :roll:
Encore une fois, le plan est calculé en fonction des statistiques de colonnes.
Vous pouvez donc extraire les caractéristiques des statistiques de colonne de votre base de données de production à l'aide de l'option STATS_STREAM de l'instruction DBCC SHOW_STATISTICS pour les ré-créer sur un serveur de développement à l'aide de l'instruction CREATE STATISTICS et de l'option du même nom ;)
@++ ;)
:ccool::resolu: