Statistiques d'attente et magasin de requêtes

Il existe de nombreux articles de blog sur ce site liés aux statistiques d'attente; il s'agit de l'une des mesures les plus importantes que vous pouvez utiliser lors de la résolution des problèmes de performances dans SQL Server. Les statistiques d'attente ont été mises à disposition dans SQL Server 2005 et représentaient traditionnellement les attentes au niveau de l'instance via sys.dm_os_wait_statistics. Ces informations sont utiles lors du dépannage des performances du système en général, mais lors de l'examen des performances des requêtes, les informations d'attente ne pouvaient être vues que lorsque la requête était en cours d'exécution et si elle attendait une ressource via sys.dm_os_waiting_tasks. Les données dans sys.dm_os_waiting_tasks sont transitoires (c'est ce qui attend en ce moment) et ne sont pas faciles à capturer et à conserver pendant toute la durée de vie d'une requête pour un réglage ultérieur des performances.

Dans SQL Server 2016, un nouveau DMV est exposé, sys.dm_exec_session_wait_stats, qui fournit des informations sur les attentes d'une session active existante. Si vous connaissez le session_id, vous pouvez suivre les attentes d'une requête au démarrage et à la fin (instantané des informations au début et à la fin de la requête, puis différenciation des informations). Le défi est que vous devez connaître le session_id pour la requête, et vous devez configurer la capture de données à l'avance - ce qui n'est pas trivial lorsque vous êtes au milieu d'un problème hautement prioritaire.

Les informations sur les statistiques d'attente existent dans un plan d'exécution réel à partir de SQL Server 2016 SP1. Seuls les 10 principaux temps d'attente sont capturés, et il y a des limites quant à ce que ces données représentent. Par exemple, CXPACKET est ignoré et non inclus dans la sortie, mais il sera inclus dans 2016 SP2 et 2017 CU3 et versions ultérieures - où les attentes de parallélisme non pertinentes sont plutôt capturées par CXCONSUMER (qui ne seront pas incluses dans les attentes réelles du plan).

Alors, comment pouvons-nous voir ce qu'une requête spécifique attend vraiment ? Nous pouvons utiliser Query Store ! SQL Server 2017 inclut la capture des informations de statistiques d'attente dans le magasin de requêtes, et cette fonctionnalité est également disponible dans Azure SQL Database. Les statistiques d'attente sont liées à un plan de requête et sont capturées au fil du temps, tout comme les statistiques d'exécution. L'ajout d'informations sur les statistiques d'attente dans Query Store était la demande de fonctionnalité numéro un après sa sortie initiale, et toutes ces informations réunies créent de puissantes capacités de dépannage.

Mise en route

La capture des statistiques d'attente dans le magasin de requêtes est activée par défaut pour Azure SQL Database. Lorsqu'une nouvelle base de données est créée dans SQL Server 2017 ou qu'une base de données est mise à niveau à partir de SQL Server 2014 ou d'une version antérieure, le magasin de requêtes est désactivé par défaut… et donc la capture des statistiques d'attente est désactivée. Lorsqu'une base de données est mise à niveau à partir de SQL Server 2016, si le magasin de requêtes est activé, la collecte des statistiques d'attente pour le magasin de requêtes sera activée lors de la mise à niveau.

À des fins de démonstration, j'ai restauré la base de données WideWorldImporters, puis j'ai exécuté les requêtes ci-dessous pour activer le magasin de requêtes et effacer toutes les données qui auraient pu exister auparavant (uniquement nécessaire car il s'agit d'un exemple de base de données) :

ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON;
GO
 
ALTER DATABASE [WideWorldImporters] SET QUERY_STORE 
(
  OPERATION_MODE = READ_WRITE
);
GO
 
ALTER DATABASE [WideWorldImporters] SET QUERY_STORE CLEAR;
GO

Les paramètres par défaut sont utilisés avec les instructions ci-dessus, et si vous souhaitez modifier l'une des options, vous pouvez le faire via l'interface utilisateur ou via l'instruction ALTER DATABASE. Maintenant que le magasin de requêtes est activé, il commencera à capturer les données de la requête, y compris le texte de la requête, le(s) plan(s), les statistiques d'exécution et les statistiques d'attente.

Regarder les statistiques d'attente

Pour générer des données, nous allons créer une procédure stockée qui exécute une requête parallèle à plusieurs reprises.

DROP PROCEDURE IF EXISTS [Sales].[OrderInfo];
GO
 
CREATE PROCEDURE [Sales].[OrderInfo]
AS
BEGIN
  WHILE 1=1
  BEGIN
    SELECT *
      FROM Sales.OrderLines ol
      INNER JOIN Warehouse.StockItems s
      ON ol.StockItemID = s.StockItemID
      OPTION (QUERYTRACEON 8649);
  END
END

Ensuite, créez un fichier .cmd avec le code suivant :

Cela nous permet de ne pas exécutez le SP dans Management Studio, ce qui crée d'importantes attentes ASYNC_NETWORK_IO ; on veut voir les attentes liées au parallélisme. Enregistrez le fichier .cmd, puis double-cliquez pour exécuter. Vous pouvez générer une charge supplémentaire en exécutant plusieurs fichiers. Avec ce scénario, nous verrons principalement les attentes liées à cette requête, car nous n'avons pas d'autre charge de travail. N'hésitez pas à exécuter simultanément d'autres requêtes sur la base de données WideWorldImporters si vous souhaitez générer encore plus de données d'attente.

Après plusieurs minutes, arrêtez les fichiers de commande et développez la base de données WideWorldImporters dans Management Studio pour voir le dossier Query Store et les rapports en dessous. Si vous ouvrez le rapport sur les requêtes les plus consommatrices de ressources, vous devriez voir la requête de procédure stockée comme la requête principale.

La vue par défaut de ce rapport affiche les requêtes avec la durée totale la plus élevée. Pour afficher les requêtes basées sur les statistiques d'attente, nous pouvons sélectionner le bouton Configurer et le modifier en Temps d'attente (ms).

Si vous survolez la barre de la première requête, vous pouvez voir les temps d'attente pour la requête. Cette vue est actuellement le seul moyen d'afficher les informations d'attente dans l'interface utilisateur, mais nous espérons que des rapports supplémentaires spécifiques aux statistiques d'attente seront disponibles dans une future version de Management Studio.

Informations d'attente dans l'interface utilisateur

Ceux d'entre vous qui ont travaillé avec les statistiques d'attente pendant un certain temps remarqueront que les descriptions des types d'attente sont différentes. Autrement dit, au lieu d'un type d'attente CXPACKET pour indiquer le parallélisme, vous voyez simplement "Type d'attente de parallélisme". Il s'agit d'une différence fondamentale dans Query Store :les types d'attente sont regroupés en catégories. Il existe plus de 900 types d'attente différents dans SQL Server à ce stade, et essayer de suivre chacun séparément est extrêmement coûteux. De plus, Query Store a été conçu pour tous les professionnels des données. Que vous soyez un expert en optimisation des performances ou que vous commenciez tout juste à comprendre le fonctionnement de SQL Server, vous devriez pouvoir utiliser Query Store pour trouver facilement les requêtes peu performantes. Cela signifie également rendre les informations d'attente plus faciles à comprendre. Pour une liste complète des catégories d'attente et des types d'attente qu'elles contiennent, veuillez consulter la documentation de sys.query_store_wait_stats.

Vous pouvez également afficher les informations d'attente à l'aide de T-SQL. Un exemple de requête est celui ci-dessous, qui inclut la requête, le(s) plan_id(s) pour cette requête et les statistiques d'attente pour un intervalle de temps donné :

SELECT TOP (10)
  [ws].[wait_category_desc],
  [ws].[avg_query_wait_time_ms],
  [ws].[total_query_wait_time_ms],
  [ws].[plan_id],
  [qt].[query_sql_text],
  [rsi].[start_time],
  [rsi].[end_time]
FROM [sys].[query_store_query_text] [qt]
JOIN [sys].[query_store_query] [q]
    ON [qt].[query_text_id] = [q].[query_text_id]
JOIN [sys].[query_store_plan] [qp] 
    ON [q].[query_id] = [qp].[query_id]
JOIN [sys].[query_store_runtime_stats] [rs] 
    ON [qp].[plan_id] = [rs].[plan_id]
JOIN [sys].[query_store_runtime_stats_interval] [rsi] 
    ON [rs].[runtime_stats_interval_id] = [rsi].[runtime_stats_interval_id]
JOIN [sys].[query_store_wait_stats] [ws]
    ON [ws].[runtime_stats_interval_id] = [rs].[runtime_stats_interval_id]
    AND [ws].[plan_id] = [qp].[plan_id]
WHERE [rsi].[end_time] > DATEADD(MINUTE, -5, GETUTCDATE()) 
AND [ws].[execution_type] = 0
ORDER BY [ws].[avg_query_wait_time_ms] DESC;

Sortie de la requête

Bien que vous puissiez désormais voir toutes les attentes pour une requête donnée et son plan, vous devrez encore approfondir les performances pour comprendre, par exemple, pourquoi une requête s'exécute en parallèle (alors que vous ne le souhaitez peut-être pas) ou ce qui pourrait bloquer une requête. Notez que les statistiques d'attente, tout comme les statistiques d'exécution, sont liées au plan de requête dans le temps. Dans cette sortie, la longueur de l'intervalle pour le magasin de requêtes est définie sur 10 minutes, de sorte que les statistiques d'attente concernent chaque plan pour cet intervalle de 10 minutes (23 h 50 le 21 novembre 2017 à minuit le 22 novembre 2017). Par défaut, la durée de l'intervalle lorsque vous activez Query Store est de 60 minutes.

Résumé

Les statistiques d'attente, combinées à des plans de requête individuels, font de Query Store un outil encore plus formidable lors du dépannage des performances du système et des requêtes. Query Store est la seule fonctionnalité qui vous permet de capturer nativement les requêtes, les plans, les mesures de performances et les statistiques d'attente au même endroit. Pour ceux d'entre vous habitués à la myriade de types d'attente, l'ajustement aux catégories utilisées dans le magasin de requêtes devrait être transparent. Pour tous ceux qui découvrent les statistiques d'attente, les catégories sont un excellent point de départ pour comprendre la ressource pour laquelle une requête est en attente.