SQL Server a toujours fourni la possibilité de capturer des requêtes en direct sur une base ad hoc dans un format d'ensemble de lignes facilement consommable - d'abord avec l'ancien SQL Server Profiler, plus tard via des événements étendus dans SSMS. Cette fonctionnalité est précieuse lors du réglage des performances, car les événements de requête incluent des métriques CPU et IO discrètes ainsi que des paramètres d'exécution, qui sont essentiels pour résoudre les problèmes de performances des requêtes tels que le reniflage de paramètres. De plus, les événements de requête contiennent d'autres éléments importants tels que le nom d'hôte du client, le nom de l'application, la connexion, l'ID de processus Windows, etc.
Vous pouvez toujours récupérer agrégé métriques de performances pour normalisé requêtes provenant de DMV ou de Query Store, mais elles ne contiennent que des requêtes compilées paramètres et aucun des éléments susmentionnés. Bien que cela soit utile, ce n'est pas la même chose. Par exemple, si vous avez besoin de voir la combinaison de paramètres spécifique utilisée par cette requête qui a effectué 2 milliards de lectures ou de trouver l'application la plus consommatrice de CPU au cours des dernières 24 heures, vous n'avez pas de chance.
Azure SQL Database n'est pas pris en charge par l'ancien profileur, et Microsoft a désactivé le fournisseur de streaming XEvents (sys.fn_MSxe_read_event_stream TVF) pour des raisons de fiabilité, de sorte que vous ne pouvez pas démarrer une session XE et « regarder les données en direct » avec SSMS. Query Performance Insights dans le portail Azure est soutenu par Query Store, de sorte que vous n'avez à nouveau que les requêtes normalisées et les données de performances agrégées, pas les événements de requête réels.
Ainsi, pendant quelques années, nous étions bloqués - la seule option pour profiler Azure SQL Database était de créer manuellement une trace XEvents qui écrit dans un tampon en anneau ou une cible de fichier avec Azure Storage, dont aucun n'est optimal. L'utilisation du tampon en anneau avec des requêtes T-SQL peut être problématique en raison de la limite XML formatée de 4 Mo, telle que couverte par Jonathan Kehayias ici, et les cibles de fichiers nécessitent une bonne quantité de sauts de cerceau et des dépenses supplémentaires. Les deux nécessitent une interrogation manuelle des données XE et ne sont donc pas exactement "en direct" au sens traditionnel.
Entrez le Nouveau Générateur de profils SQL Server
Lorsque j'ai entendu parler de l'extension SQL Server Profiler pour Azure Data Studio, j'ai été ravi de voir Microsoft proposer enfin une solution graphique pour la capture de requêtes en direct sur Azure SQL Database. Malheureusement, mon enthousiasme a été de courte durée pour plusieurs raisons.
Tout d'abord, la redoutable trace "Standard" de l'ancien Profiler a apparemment été utilisée comme modèle pour la session ADS Profiler XE pour Azure SQL Database , nommé ADS_Standard_Azure par défaut. (Les sessions XE utilisées pour SQL Server complet sont similaires.) Comme j'ai blogué il y a plusieurs années et que je le crois toujours, la trace standard est l'une des principales raisons pour lesquelles l'ancien Profiler est si mal considéré. Il contient plusieurs événements inutiles et non filtrables tels que le démarrage du batch SQL , se connecter et déconnexion , et par conséquent, il n'ajoute aucune valeur réelle pour le réglage des performances. De plus, avec l'architecture de trace d'ensemble de lignes synchrone utilisée par l'ancien Profiler, le volume élevé d'événements peut avoir un impact sur les performances des systèmes occupés. Pour une raison quelconque, cette chose ne va pas disparaître !
| |
| Événements de trace "Standard" de Legacy Profiler |
Événements XE "ADS_Standard_Azure" d'ADS Profiler |
Deuxièmement, il utilise un tampon en anneau d'une taille maximale de 8 Mo ou 1000 événements, selon la première éventualité. Parce que les événements de connexion/déconnexion sont petits, vous atteindrez souvent 1000 événements bien avant d'atteindre la limite de 8 Mo, ou même la limite XML formatée de 4 Mo. Cependant, avec un mélange modéré d'événements SQL, le tampon en anneau XML sera toujours de 2 à 3 Mo à 1000 événements dans mes tests, et le problème est que ce tampon entier est tiré sur le réseau chaque fois que l'extension Profiler interroge pour rafraîchir sa grille , qui est la plus longue de chaque 1 seconde ou durée du sondage précédent. Le XML est ensuite analysé côté client par l'extension ADS Profiler pour déterminer quels événements sont nouveaux depuis le dernier sondage, et les nouveaux événements sont ajoutés à la grille.
La mémoire tampon en anneau se remplit presque instantanément, même sur un serveur modérément occupé, et l'effet net est que vous tirerez rapidement>40 mégabits par seconde sur le réseau à partir de votre base de données SQL Azure . Cela se traduit par 300 mégaoctets par minute, ou 18 gigaoctets par heure !
Accès réseau de l'extension ADS Profiler (plage de 4 minutes)
Ma crainte initiale était que cela pourrait entraîner d'énormes frais de sortie sur la prochaine facture Azure, cependant, en examinant nos propres abonnements Azure, nous n'avons pas été en mesure de confirmer que le trafic réseau pour Azure SQL DB est facturé. Mike Wood (b|t) de SentryOne, un MVP Azure, a passé des semaines à essayer de trouver la réponse et a finalement appris de Microsoft qu'en effet la sortie réseau n'est actuellement pas facturée pour Azure SQL DB, bien que cela puisse changer à tout moment. Même ainsi, extraire 18 Go de données de requête par heure ne semble pas responsable et pourrait certainement mettre un frein à votre prochaine session de visionnage excessif de Netflix.
Bien que vous puissiez définir des filtres via l'interface utilisateur du profileur, ce qui facilitera l'examen des données, cela ne réduira pas l'impact sur le réseau car ils fonctionnent côté client.
Une session XE mise à jour
Une solution rapide pour réduire la charge réseau d'ADS Profiler et rendre les données beaucoup plus consommables pour le réglage des performances des requêtes consiste à mettre à jour ADS_Standard_Azure Séance XE. Vous trouverez ci-dessous un script qui :
- Supprimez les événements inutiles :
- sqlserver.attention
- sqlserver.existing_connection
- sqlserver.login
- sqlserver.logout
- sqlserver.sql_batch_starting
- Définissez un seuil de durée> 1 seconde (1000000 microsecondes) sur les événements restants :
- sqlserver.rpc_completed
- sqlserver.sql_batch_completed
- Réduire la taille maximale de la mémoire tampon circulaire de 1 000 à 10 événements
- Cela ne fonctionnerait jamais avec la trace d'origine car 10 événements seront générés en millisecondes et le tampon circulaire se recyclerait trop rapidement, ce qui entraînerait la perte de la plupart des événements. Cependant, avec le filtre de durée de 1 seconde, le flux d'événements sera beaucoup plus faible et 10 événements devraient bien fonctionner avec l'intervalle d'interrogation de 1 seconde utilisé par le profileur ADS.
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
DROP EVENT sqlserver.attention,
DROP EVENT sqlserver.existing_connection,
DROP EVENT sqlserver.login,
DROP EVENT sqlserver.logout,
DROP EVENT sqlserver.rpc_completed,
DROP EVENT sqlserver.sql_batch_completed,
DROP EVENT sqlserver.sql_batch_starting
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
ADD EVENT sqlserver.rpc_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000)))),
ADD EVENT sqlserver.sql_batch_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000))))
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
DROP TARGET package0.ring_buffer
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
ADD TARGET package0.ring_buffer(SET max_events_limit=(10),max_memory=(51200))
GO Après avoir appliqué le script pour mettre à jour la session XE, le firehose sera immédiatement réduit à un filet :
Accès réseau réduit après la mise à jour de la session ADS Profiler XE
Alternatives encore plus légères
SQL Sentry et son homologue SaaS SentryOne Monitor sont les seules autres solutions que je connaisse pour capturer les requêtes d'Azure SQL Database, et ils le font en utilisant une approche innovante qui est considérablement plus légère que la session XE optimisée ci-dessus pour ADS Profiler. Entre autres fonctionnalités avancées, vous pouvez facilement regrouper par nom d'hôte client, application et connexion, et capturer automatiquement des plans de requête pour analyse avec l'explorateur de plans intégré.
SentryOne Monitor affichant les requêtes et les plans capturés à partir d'Azure SQL Database
Fermeture
Microsoft a déclaré qu'il continuerait à améliorer l'extension ADS Profiler et, lorsqu'il le fera, j'espère qu'il résoudra les problèmes décrits ci-dessus. J'ai consigné le problème ici. En attendant, le script mis à jour offrira une expérience de profilage des requêtes plus sûre et plus conviviale pour Azure SQL Database.
