Fonctionnalités obsolètes à retirer de votre boîte à outils – Partie 2

Dans mon dernier message, j'ai illustré une raison pour laquelle vous devriez arrêter d'utiliser des tables système obsolètes comme sysprocesses . Ce n'était pas pour des raisons de performances, directement, ou simplement pour suivre les meilleures pratiques documentées de Microsoft, mais tournait davantage autour des décisions que vous pourriez prendre lorsque vous n'avez accès qu'à certaines données.

Cette fois-ci, je veux parler d'une fonctionnalité incluse avec les outils clients SQL Server que nous ne devrions pas utiliser ces jours-ci - non seulement parce qu'elle est obsolète mais, plus important encore, parce qu'elle a le potentiel de complètement arrêter un serveur :

Profilateur SQL Server

Depuis SQL Server 2012 (et, dans une bien moindre mesure, depuis SQL Server 2008), la solution la plus complète et la plus flexible pour surveiller les événements sur une instance SQL Server est Extended Events. D'un autre côté, depuis qu'il a été inventé (à peu près au moment où j'ai commencé ma carrière), SQL Server Profiler a été l'un des moyens les plus prolifiques de mettre accidentellement un serveur à genoux.

Il n'y a pas si longtemps, quelque chose comme ça nous est arrivé. Un développeur a modifié son application pour réduire le nombre d'allers-retours qu'il effectuait. Ils ont exécuté l'application localement et dans notre environnement de développement, en utilisant Profiler avec une trace filtrée, pour confirmer que leurs modifications fonctionnaient comme prévu. Permettez-moi de vous rappeler à ce stade que la documentation officielle de SQL Server Profiler inclut l'avertissement suivant :

Quoi qu'il en soit, lorsqu'ils ont déployé la nouvelle version de leur application en production et ciblé le serveur de production avec la même trace filtrée, cela ne s'est pas si bien passé. Leur filtre générique sur le nom de l'application n'a pas pris en compte les autres applications (nommées de manière similaire) se connectant également à ce serveur, et ils ont immédiatement commencé à capturer beaucoup plus d'informations que leur fenêtre Profiler ouverte ne pouvait en gérer. Cela a entraîné une augmentation catastrophique du temps de connexion pour tous les utilisateurs et applications se connectant à cette instance. Ce serait un euphémisme de dire que des plaintes ont été déposées.

Lorsque le coupable a été déterminé et que nous avons reçu une réponse du développeur, vous pouvez voir que le temps de connexion est redescendu à la normale presque immédiatement après l'arrêt de sa trace Profiler (cliquez pour agrandir) :

Un mini-désastre SQL Server Profiler

Il s'agit certainement d'un scénario où l'ancienne déclaration "a travaillé sur ma machine" ne signifie en aucun cas qu'elle fonctionnera bien sur un serveur de production occupé. Et cet incident a conduit à une conversation active autour de la modification du déclencheur de connexion qui existe déjà sur tous les serveurs de notre environnement pour simplement bloquer le nom d'application que Profiler transmet dans sa chaîne de connexion.

Peut-être que ce n'est pas un problème de Profiler. (Mais c'est un peu le cas.)

Je ne suis pas ici pour suggérer que d'autres outils de surveillance, y compris les événements étendus, ne peuvent pas être utilisés de manière inappropriée pour faire tomber un serveur d'une manière similaire (ou pire !). Il existe de nombreuses opportunités d'affecter par inadvertance une instance de SQL Server, de manière très défavorable, sans toucher au SQL Server Profiler.

Mais Profiler est connu pour ce type de symptôme en raison de la façon dont il consomme Les données. Il s'agit d'une interface utilisateur avec une grille qui présente les nouvelles lignes au fur et à mesure qu'elle les reçoit; malheureusement, cela fait attendre SQL Server pendant qu'il les rend avant de permettre à SQL Server de transmettre plus de lignes. Ce comportement est similaire à la façon dont SQL Server Management Studio peut ralentir les requêtes et provoquer des ASYNC_NETWORK_IO élevés attend pendant qu'il essaie de restituer une grande quantité de sortie à sa propre grille. C'est une simplification (et ne doit pas être confondue avec la façon dont la trace SQL sous-jacente peut être amenée à se comporter, ce que Greg Gonzalez (@SQLsensei) explique dans "Don't Fear the Trace"), mais c'est exactement ce qui conduit à le type de scénario présenté ci-dessus :ce goulot d'étranglement a un effet en cascade sur tous les autres processus essayant de faire quoi que ce soit dans le même chemin de code que ce que vous tracez (y compris en essayant d'établir une connexion).

Peur des événements prolongés ?

Ne soyez pas. Il est grand temps que nous abandonnions tous Profiler et embrassions le présent . Les didacticiels et guides ne manquent pas, y compris le QuickStart de Microsoft et plusieurs articles ici même sur ce site.

Si vous avez des traces existantes sur lesquelles vous comptez, Jonathan Kehayias (@SQLPoolBoy) a un script très pratique pour convertir une trace existante en événements étendus. Vous pouvez toujours vous sentir libre de configurer la trace d'origine avec l'interface utilisateur de Profiler, si c'est là que vous êtes le plus à l'aise ; faites-le simplement sans vous connecter à un serveur de production. Vous pouvez en savoir plus sur ce script ici et voir certains des autres articles de Jonathan sur les événements prolongés ici.

Si vous rencontrez des difficultés avec l'expérience utilisateur, vous n'êtes pas seul, mais il existe des réponses :

• Erin Stellato (@erinstellato) est depuis longtemps un défenseur spectaculaire des événements étendus et se demande souvent à haute voix pourquoi les gens hésitent à abandonner Profiler et SQL Trace en général. Elle a un aperçu (et a inspiré beaucoup de commentaires) dans son article de 2016, « Pourquoi évitez-VOUS les événements prolongés ? » ; peut-être y a-t-il un aperçu de la question de savoir si vos raisons de tenir bon sont toujours (aussi) valables en 2021.
  
• Il existe un profileur XEvent intégré aux versions modernes de SSMS, avec une extension équivalente pour Azure Data Studio. Bien que, de manière confuse, ils aient appelé cette extension - de toutes les choses que l'on pourrait imaginer - Profileur SQL Server . Erin a également quelques réflexions sur ce choix.
  
• Erik Darling (@erikdarlingdata) a créé sp_HumanEvents pour soulager une partie de la douleur liée au passage aux événements étendus. L'une de mes personnes préférées "s'en tenir à l'essentiel", Erik décrit sp_HumanEvents comme suit :"Si vous voulez un moyen simple de profiler les métriques de requête, les statistiques d'attente, le blocage, la compilation ou la recompilation avec des événements étendus, c'est votre licorne."