Webinaire Plan Explorer 3.0 – Exemples et questions-réponses

Vendredi dernier, j'ai donné un webinaire sur Plan Explorer 3.0, les nouvelles fonctionnalités et pourquoi nous avons décidé d'éliminer l'édition PRO et d'offrir toutes les fonctionnalités gratuitement . Si vous l'avez manqué, vous pouvez regarder le webinaire ici :

Webinaire Plan Explorer 3.0

De nombreuses questions intéressantes ont été soumises, et je vais essayer d'y répondre ici. Nous avons également posé quelques-unes de nos propres questions à différents moments de la présentation, et les utilisateurs ont demandé des détails à ce sujet. Je vais donc commencer par les questions du sondage. Nous avons eu un pic de 502 participants, et j'indiquerai sur les tableaux ci-dessous combien de personnes ont répondu à chaque question. Étant donné que la première question a été posée avant le début technique du webinaire, un plus petit nombre de personnes ont répondu à celle-ci.

Questions du public

Q :Les exemples de code sont-ils disponibles ?

R : Oui, les trois fichiers de session que j'ai utilisés pour mes démos sont disponibles ici :

Démos de webinaires Plan Explorer 3.0

Vous pouvez les ouvrir dans la dernière version de Plan Explorer, mais si vous souhaitez réexécuter l'une des requêtes localement, vous aurez besoin d'AdventureWorks2014 (avec le script d'agrandissement de Jonathan Kehayias) et/ou de la nouvelle base de données exemple Wide World Importers.

R : Je suis toujours surpris quand je rencontre des gens qui pensent que tout ce que nous offrons est Plan Explorer (je les vois en personne, et il y avait aussi plusieurs commentaires similaires sur le blog de Greg). Notre véritable pain et beurre se trouve dans notre plate-forme de surveillance, et nous espérons que votre expérience positive avec Plan Explorer vous incitera également à essayer nos autres solutions.

R : Oui, bien que vous manquiez de certaines fonctionnalités (telles que le profil de requête en direct), il y a beaucoup plus d'informations à votre disposition par rapport à SSMS, et nous nous efforçons de rendre les problèmes spécifiques beaucoup plus faciles à découvrir.

R : Oui, tant que le Service Pack 1 est appliqué, car la fonctionnalité repose sur un DMV qui a été ajouté dans SQL Server 2014 SP1.

R : Absolument. La limitation que j'ai évoquée lors du webinaire sur SQL Server 2012 et les versions antérieures est qu'ils ne sont pas en mesure de capturer les données du profil de requête en direct.

R : Oui, Live Query Profile (et les graphiques de ressources) fonctionnent dans SQL Server 2014 (avec au moins SP1), SQL Server 2016 et Azure SQL Database. Il n'est pas affecté par le niveau de compatibilité.

R : La collecte des statistiques d'attente repose sur une session d'événements étendus, vous devez donc exécuter SQL Server 2008 ou supérieur et exécuter dans le contexte d'un utilisateur ou d'une connexion avec suffisamment d'autorisations pour créer et supprimer une session d'événements étendus (CONTROL SERVER dans SQL Server 2008 et 2008 R2, et ALTER ANY EVENT SESSION dans SQL Server 2012 et supérieur).

R : Il y avait de nombreuses variantes sur ces deux questions, et d'après ce qu'elles entendaient, les gens jouaient activement avec la nouvelle version pendant le webinaire, et ne voyaient ni les données d'analyse de l'index ni les données du profil de requête en direct. Si vous avez un plan existant capturé à partir de SSMS ou d'une version antérieure de Plan Explorer, il n'y aura aucune information à afficher.

Afin de collecter l'analyse de l'indice données, vous devez générer un plan prévisionnel ou réel à partir de Plan Explorer. Pour voir une grille de colonnes et d'index, vous devez choisir une opération sélectionnée :dans le menu déroulant en haut de l'onglet Analyse d'index.

Afin de collecter le profil de requête en direct données, vous devez générer un plan réel depuis Plan Explorer et exécuter avec 2014 SP1 ou supérieur. Vous devez également vous assurer que vous avez sélectionné l'option "Avec le profil de requête en direct" (voir l'image à droite) et attendre la fin de l'exécution de la requête avant que les graphiques ne s'affichent. Dans une future version, les graphiques s'afficheront en temps réel, mais dans cette version, nous le faisons une fois que toutes les données ont été collectées.

R : Oui, cela fonctionnera, mais cela ne fournira pas beaucoup d'informations car une base de données clonée est vide - vous verrez les bonnes estimations dans le plan, mais les valeurs réelles seront toutes de 0, et donc les métriques d'exécution ne représenteront aucun réalisme ou des goulots d'étranglement significatifs. À moins que vous ne remplissiez le clone avec des données alternatives, comme Erin Stellato le promeut dans un article précédent. Notez également que si vous souhaitez que les plans de requête reflètent les tailles réelles des données de production, vous devez vous assurer que toutes les formes de statistiques automatiques sont désactivées, sinon elles seront mises à jour au fur et à mesure que vous exécutez des requêtes, puis toutes les estimations seront 0.

R : Oui. Nous prenons en charge tous les nouveaux opérateurs de plan SQL Server 2016 et d'autres modifications du plan de présentation (voir mon article, « Plan Explorer Support for SQL Server 2016 »), et le complément fonctionne également avec la dernière version de SSMS (voir mon article, "Annonce de la prise en charge du complément Plan Explorer pour SSMS 2016").

R : Oui c'est vrai. Lorsque vous capturez les données du profil de requête en direct, nous pouvons modifier les pourcentages de coût pour tous les opérateurs, car nous savons avec un degré de précision significatif la quantité de travail réel effectuée par chaque opération (la requête doit cependant s'exécuter plus longtemps qu'un seuil). Cela peut être particulièrement utile si vous résolvez un problème d'E/S, car les estimations ne semblent jamais prendre en compte les goulots d'étranglement d'E/S. Le graphique suivant parcourt les estimations d'origine (nous pouvons toujours vous montrer ce que SSMS vous aurait dit), les chiffres réels après recalcul et les chiffres réels après recalcul et modification des coûts en "par E/S" et des largeurs de ligne à "par taille de données":

R : J'ai abordé cette question dans le webinaire, mais pour être clair, je pense qu'il y a deux étapes dans l'évolution d'une requête :(1) garantir des résultats corrects et (2) optimiser les performances. Je crois fermement que vous devriez actuellement utiliser SSMS pour (1) et Plan Explorer pour (2). J'ai longtemps promu qu'une fois que les gens sont sûrs d'avoir des résultats corrects, ils doivent s'adapter en générant des résultats réels plans d'exécution depuis Plan Explorer, car nous recueillons beaucoup plus d'informations d'exécution pour vous. Ces informations d'exécution sont particulièrement utiles si vous partagez vos plans sur notre site de questions-réponses, car elles rendent toutes les mesures et les goulots d'étranglement potentiels beaucoup plus apparents.

R : Ce pourcentage n'est pas un coût mais plutôt le % de lignes réellement traitées par rapport à l'estimation. Dans ce cas, SQL Server a estimé que la fonction renverrait 10 000 lignes, mais à l'exécution, elle en renvoyait près de 300 000 ! Vous pouvez voir une info-bulle si vous survolez uniquement ce pourcentage, et vous pouvez voir les différences d'estimation du nombre de lignes dans l'info-bulle de l'opérateur, ou dans d'autres grilles comme Top Operations (la fonction renvoie un nombre de lignes différent maintenant qu'il ne l'a fait pendant la démo):

R : Oui, tous nos panneaux sont réglables; beaucoup ont une punaise qui bascule entre statique et masquage automatique, la plupart des panneaux peuvent être déplacés (comme dans Visual Studio, SSMS, etc.), et le panneau de relecture en particulier a une petite flèche en haut au centre qui vous permet pour afficher/masquer rapidement :

R : Je ne sais pas si j'interprète correctement la question, mais tous nos panneaux sont sensibles au contexte, et la déclaration du plan en cours d'examen s'affiche à la fois dans la grille Déclaration et dans le panneau Données textuelles :

Si le texte de la déclaration n'est pas entièrement visible en raison de sa longueur, vous pouvez toujours cliquer avec le bouton droit sur cette cellule et choisir Copier la déclaration dans la copie du texte de la commande, puis basculer vers cet onglet. Ou, si vous ne voulez pas écraser le contenu actuel de l'onglet Texte de la commande, choisissez Copier> Cellule et collez dans une nouvelle session, SSMS ou un autre éditeur.

R : Si une requête est en cours d'exécution, un bouton Arrêter est présent dans la barre d'état, en bas à gauche :

R : Nous prévoyons certainement de rendre les scripts d'index plus robustes à l'avenir, y compris des options telles que DROP_EXISTING et ONLINE.

R : Toutes les fonctionnalités de Plan Explorer sont également disponibles dans SentryOne Client. Techniquement, vous n'avez pas besoin d'installer Plan Explorer si vous avez le client, sauf que les mises à jour sont poussées selon un calendrier différent, donc dans de nombreux cas, il peut être judicieux d'installer les deux.

Gardez à l'esprit que les plans que nous collectons pour vous pendant les activités de surveillance sont des plans estimés, en raison du coût élevé de la collecte des plans réels pour toutes les requêtes exécutées sur un serveur. Cela signifie que si vous explorez un plan collecté dans le client, il ne contiendra pas d'informations supplémentaires telles que les données d'analyse d'index et de profil de requête en direct. Vous pouvez toujours réexécuter la requête, de manière interactive, afin d'obtenir ces données d'exécution supplémentaires.

R : La plupart des informations que nous collectons ne sont pas plus chères que si vous exécutiez les mêmes requêtes et collectiez les mêmes données d'exécution à partir de Management Studio (par exemple, avec SHOWPLAN, STATISTICS TIME et STATISTICS IO activés). Cependant, une grande partie de cela est compensée par notre comportement par défaut de suppression des résultats, de sorte que nous ne surchargeons pas le serveur avec l'effort de transmission des résultats à notre application.

Pour les plans extrêmement complexes exécutés sur des bases de données avec des schémas très complexes et BEAUCOUP d'index, la collecte d'index et de statistiques peut être moins efficace, mais il est extrêmement peu probable que cela ait un impact notable sur les charges de travail existantes. Cela ne sera pas affecté par le nombre de lignes dans un tableau, qui a été mentionné dans une variante de cette question.

Pour les requêtes très longues ou gourmandes en ressources, ma plus grande préoccupation serait notre collection Live Query Profile. Nous avons deux préférences qui peuvent vous aider :s'il faut inclure le profil de requête en direct avec toute la génération de plan réelle par défaut, et quel intervalle de collecte des données à partir du DMV. Bien que je pense toujours que la surcharge de cette collection ne devrait jamais se rapprocher de la surcharge de la requête elle-même, vous pouvez modifier ces paramètres pour rendre la collection moins agressive.

Cela dit, avec la clause de non-responsabilité selon laquelle tout doit être fait avec modération, je n'ai observé aucun problème lié à la surcharge de collecte des données et n'hésiterais pas à utiliser toutes les fonctionnalités contre une instance de production.

R : Actuellement, nous n'avons aucune fonctionnalité qui recommande des index filtrés, mais c'est définitivement sur notre radar.

R : Oui, cela faisait certainement partie de notre feuille de route bien avant que cette fonctionnalité ne soit introduite dans SSMS. :-) Nous allons prendre notre temps et créer un ensemble de fonctionnalités que vous attendez de nous, espérons-le.

R : Je suppose que vous le pouvez, si vous appelez le package ou le travail via T-SQL sur un serveur (Plan Explorer n'a pas la capacité de lancer directement des choses comme les packages SSIS). Mais l'application n'affichera que les aspects de performance rendus visibles via SQL Server - s'il y a des inefficacités dans le package SSIS qui ne sont pas liées à l'exécution contre SQL Server (par exemple, une boucle infinie dans une tâche de script), nous sommes nous ne pourrons pas les récupérer, car nous n'avons aucune visibilité et n'effectuons aucune analyse de code.

R : J'ai raté cette question pendant le webinaire, mais je parle de cette fonctionnalité dans mon kit de démonstration, Jonathan Kehayias a blogué à ce sujet ici, Steve Wright a une vidéo à ce sujet sur YouTube, et la documentation officielle peut être consultée dans le Guide de l'utilisateur PE.

R : Plan Explorer est conçu pour aider à analyser les requêtes individuelles et leurs plans d'exécution. Nous disposons d'une plate-forme de surveillance complète pour les efforts de plus grande envergure, et il existe également plusieurs outils d'analyse de charge de travail tiers.

R : Il existe de nombreuses ressources pour améliorer le réglage des requêtes :

• N'importe quel livre T-SQL d'Itzik Ben-Gan, Grant Fritchey ou Benjamin Nevarez ;
• Tout article de blog rédigé par Paul White ou Rob Farley ;
• Questions et réponses ici sur answers.sqlperformance.com ou sur dba.stackexchange.com ;
• Vidéos de réglage des requêtes sur YouTube ;
• Le kit de démonstration (avec une nouvelle version à venir !) ; et,
• Pratiquer . Sérieusement. Vous pouvez lire tous les livres et articles que vous voulez, mais sans un travail pratique de dépannage et d'amélioration des requêtes problématiques avec de réels problèmes de performances, il sera difficile de devenir un expert. À mon humble avis.

Résumé

Merci d'avoir participé au webinaire et merci beaucoup pour toutes ces bonnes questions. Je suis désolé de ne pas avoir pu tous les aborder, mais j'espère que cela vous a néanmoins été utile. Si vous aviez une question que je n'ai pas abordée ci-dessus, n'hésitez pas à me la poser directement à [email protected].