Exploration de l'interface graphique du magasin de requêtes SQL Server 2016

Présentation

Le magasin de requêtes est une nouvelle fonctionnalité, introduite dans SQL Server 2016, qui permet aux administrateurs de base de données d'examiner historiquement les requêtes et leurs plans associés à l'aide de l'interface graphique disponible dans SQL Server Management Studio, ainsi que d'analyser les performances des requêtes à l'aide de certaines vues de gestion dynamique. Query Store est une option de configuration étendue à la base de données et peut être utilisée si le niveau de compatibilité de la base de données en question est de 130.

Query Store est similaire à des technologies de la plate-forme de base de données Oracle telles que Automatic Workload Repository (AWR). L'AWR capture des statistiques de performances à une échelle encore plus grande que Query Store et permet à un administrateur de base de données d'analyser historiquement les performances. Des concepts tels que la période de conservation et les limites de stockage des données collectées sont disponibles dans l'architecture AWR comme ils le sont dans le magasin de requêtes. Les principales options de configuration suivantes sont disponibles lors de l'activation de Query Store :

Mode de fonctionnement : Détermine si le magasin de requêtes acceptera les données nouvellement capturées (mode lecture/écriture) ou stockera simplement les anciennes données disponibles pour les rapports (mode lecture seule)
Intervalle de vidage des données : Détermine la fréquence à laquelle les tampons de mémoire du magasin de requêtes sont vidés sur un disque. Rappelez-vous que les données du magasin de requêtes sont stockées dans la base de données où le magasin de requêtes est activé. La valeur par défaut est de 15 minutes.
Intervalle de collecte des statistiques : Détermine la fréquence de collecte des statistiques d'exécution du magasin de requêtes.
Taille maximale : Détermine dans quelle mesure le référentiel pour les statistiques du magasin de requêtes peut croître. Par défaut, il s'agit de 100 Mo.
Mode de capture du magasin de requêtes : Détermine la granularité des captures de requête. TOUT, AUTO et AUCUN sont les options disponibles. La valeur par défaut est AUTO.
Mode de nettoyage basé sur la taille : Détermine si Query Store videra les anciennes données lorsque la taille maximale sera atteinte.
Seuil de requête obsolète : Détermine le nombre de jours pendant lesquels le magasin de requêtes conserve les données. La valeur par défaut est fixée à trente jours.

Fig. 2 Options de requête du magasin

Le magasin de requêtes est une fonctionnalité étendue à la base de données qui peut être activée à l'aide de l'interface graphique (SQL Server Management Studio) ou en exécutant la commande suivante :

ALTER DATABASE [WideWorldImporters] SET QUERY_STORE =ON ;

La télémétrie de requête collectée par Query Store est stockée dans des tables système au sein de la base de données où Query Store a été activé.

Exemples de requêtes et rapports par défaut

Jusqu'à présent, tout ce que j'ai écrit est disponible auprès de nombreuses autres sources; certains d'entre eux peuvent être trouvés dans la section des références.

Dans cette section, nous examinerons un peu plus en détail ce que nous pouvons réellement faire avec Query Store une fois que nous l'avons activé à l'aide d'exemples simples. Considérons les deux requêtes suivantes :

Liste 1 :Récupérer des enregistrements à l'aide d'un filtre spécifique

utilisez WideWorldImporters pour sélectionner un. pré>

Liste 2 :Récupérer des enregistrements à l'aide d'une plage

use WideWorldImportersgoselecta.ContactPersonID,a.OrderDate,a.DeliveryMethodID,a.Comments,b.OrderedOutersfromPurchasing.PurchaseOrders ainner join Purchasing.PurchaseOrderLines bon a.PurchaseOrderID=b.PurchaseOrderIDwhere a.SupplierReference like 'ML%';go 1500

Faites attention à la version alternative de ces requêtes écrites en majuscule :

Liste 1 :Récupérer des enregistrements à l'aide d'un filtre spécifique (majuscules)

UTILISEZ WIDEWORLDIMPORTERSGOSELECTA.CONTACTPERSONID,A.ORDERDATE,A.DELIVERYMETHODID,A.COMMENTS,B.ORDEREDOUTERSFROMPURCHASING.PURCHASEORDERS AINNER JOIN PURCHASING.PURCHASEORDERLINES BON A.PURCHASEORDERID=B.PURCHASEORDERIDWHERE A.SUPPLIERREFERENCE='ML0300 502'; pré>

Liste 2 :Récupérer des enregistrements à l'aide d'une plage (majuscules)

USE WIDEWORLDIMPORTERSGOSELECTA.CONTACTPERSONID,A.ORDERDATE,A.DELIVERYMETHODID,A.COMMENTS,B.ORDEREDOUTERSFROMPURCHASING.PURCHASEORDERS AINNER JOIN PURCHASING.PURCHASEORDERLINES BON A.PURCHASEORDERID=B.PURCHASEORDERIDWHERE A.SUPPLIERREFERENCE LIKE 'ML%';GO 25 /pré>

Comme vous pouvez le voir, nous avons exécuté ces requêtes plusieurs fois en utilisant le mot-clé GO. Ainsi, nous avons une quantité raisonnable de données avec lesquelles travailler. La première chose dont nous devons être conscients lorsque nous utilisons le magasin de requêtes pour analyser les performances est qu'il existe six rapports par défaut intégrés au magasin de requêtes SQL Server 2016, comme illustré à la figure 3.

Fig. 3 Interroger les rapports du magasin

Les noms des rapports sont décrits en détail dans les articles précédents ainsi que dans la documentation Microsoft. Les données fournies par ces rapports sont extraites des principales vues de gestion dynamique répertoriées ci-dessous :

VDM des statistiques du plan

sys.query_store_query_text – contient des textes de requête uniques exécutés sur la base de données
sys.query_store_plan – contient un plan estimé pour la requête avec les statistiques de temps de compilation
sys.query_context_settings – contient des combinaisons uniques du plan affectant les paramètres sous lesquels les requêtes sont exécutées
sys.query_store_query – les entrées de requête qui sont suivies et forcées séparément dans le magasin de requêtes

DMV des statistiques d'exécution

sys.query_store_runtime_stats_interval – Query Store divise le temps en fenêtres de temps générées automatiquement (intervalles) et stocke des statistiques agrégées sur cet intervalle pour chaque plan exécuté
sys.query_store_runtime_stats - contient des statistiques d'exécution agrégées pour les plans exécutés

Beaucoup plus de détails sur l'utilisation de ces DMV sont disponibles dans la documentation Microsoft référencée. Dans cet article, nous utiliserons principalement l'interface graphique.

Comme vous pouvez le voir sur la Fig. 4, nous examinons le rapport sur la consommation globale des ressources tandis que dans la section suivante, nous allons nous limiter aux requêtes que nous avons répertoriées précédemment et aux données que nous pouvons récupérer à partir de ces requêtes simples.

Fig. 4 Rapport sur la consommation globale des ressources

Analyse des requêtes à l'aide de l'interface graphique

Quelques éléments clés doivent être considérés comme utiles lors de l'utilisation des rapports du magasin de requêtes :

Vous pouvez configurer l'environnement en cliquant sur le bouton mis en surbrillance dans la Fig. 4. La Fig. 5 nous montre les détails que nous pouvons modifier en fonction de notre cas d'utilisation :critères de données à renvoyer, plage de dates et ensemble de données à renvoyer. Par exemple, si je veux voir clairement l'ID de requête associé aux requêtes que j'examine, je voudrais réduire mon ensemble de données du Top 25 par défaut au Top 10, par exemple.
Fig. 5 Options de configuration du rapport

Fig. 6 Top 25 des requêtes exécutées le 1er mai 2018

Fig. 7 Top 10 des requêtes exécutées le 1er mai 2018
Les graphiques à barres affichent les données principalement avec le temps sur l'axe X, mais vous pouvez explorer un point de données spécifique pour afficher les données en fonction des ID de requête. Chaque ID de requête détermine une requête spécifique. Il est important de noter qu'une requête est identifiée de manière unique en hachant le texte. Ainsi, une requête en minuscules diffère de la même requête en majuscules. Cela devrait être une connaissance commune :les requêtes ad hoc sont une préoccupation pour le cache de plan et elles sont également mauvaises pour le magasin de requêtes, à la fois en termes d'utilisation de l'espace et d'analyse appropriée.
Fig. 8 Requête dans le listing 1 (minuscules, requête 42480)

Fig. 9 Requête dans le Listing 3 (Majuscules, Requête 42490)
La troisième observation importante est le fait que lorsqu'un point de données est surligné en vert, le plan d'exécution détaillé affiché dans le volet inférieur se rapporte à ce point de données. Dans la Fig. 7, ce point de données fait référence à la requête ID 42481 que nous avons exécutée précédemment (requête complète illustrée dans la liste 2). Passer notre souris sur ce point de données affiche la requête, son ID et le nombre de plans associés à cette requête (voir Fig. 8).
Fig. 10 Détails de la requête 42481

Notre requête a été exécutée 1391 fois car elle est capturée avec précision par Query Store et affichée sur l'axe des ordonnées (nombre d'exécutions) du graphique à barres de la Fig. 10. Le rapport était extrait alors que le lot était encore en cours d'exécution. Ainsi, nous n'avons pas le décompte complet (1500) nous informant qu'il y a une capture en temps réel des données à chaque fois qu'une requête est exécutée. A droite, on voit également le Plan servant à ces multiples exécutions (Plan 675). Nous pouvons le vérifier en utilisant la requête du Listing 5.

Liste 5

UTILISER WideWorldImportersGOSELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*FROM sys.query_store_plan AS PlJOIN sys.query_store_query AS Qry ON Pl.query_id =Qry.query_idJOIN sys.query_store_query_text AS Txt ON Qry.query_text_id =Txt .query_text_idwhere Qry.query_id=42481 ;

Fig. 11 ID de requête et ID de plan à partir des DMV

Un peu de réglage

Examinons une autre requête.

Lorsque nous exécutons la requête dans la liste 6 et examinons les détails du magasin de requêtes, les détails du plan d'exécution révèlent que nous avons besoin d'un index pour obtenir une amélioration de 51 %.

Liste 6 :Requête sous-optimale

SELECT TOP (1000) [OrderLineID] ,[OrderID] ,[StockItemID] ,[Description] ,[PackageTypeID] ,[Quantity] ,[UnitPrice] ,[TaxRate] ,[PickedQuantity] ,[PickingCompletedWhen] ,[LastEditedBy ] ,[LastEditedWhen] FROM [WideWorldImporters].[Sales].[OrderLines] where unitPrice> 1000 GO 2000

Fig. 12 Détails de requête sous-optimaux

Fig. 13 Plan d'exécution de requête sous-optimal

Une fois que nous avons créé l'index recommandé à l'aide de l'instruction du Listing 7, nous amenons l'Optimiseur de requête à générer un nouveau plan d'exécution. Dans ce cas, le nouveau plan d'exécution devrait améliorer les performances. Cependant, il existe des cas où certaines modifications peuvent entraîner une dégradation des performances, telles que des modifications importantes du volume de données qui invalident efficacement les statistiques ou réduisent le nombre d'index, etc. On dit que ces requêtes ont régressé en termes de performances et peuvent être examinées à l'aide du rapport sur les requêtes en régression dans le magasin de requêtes.

Liste 7 :Création d'un index

USE [WideWorldImporters]GOCREATE INDEX NON CLUSTÉRÉ [Custom_IX_UnitPrice]ON [Sales].[OrderLines] ([UnitPrice])INCLUDE([OrderLineID],[OrderID],[StockItemID],[Description],[PackageTypeID],[Quantité ],[TaxRate],[PickedQuantity],[PickingCompletedWhen],[LastEditedBy],[LastEditedWhen])GO

Fig. 14 Requête optimisée (Modification du plan d'exécution)

Fig. 15 Requête optimisée (deux plans)

Fig. 16 Requête optimisée (plan de force)

Lorsqu'il existe plusieurs plans pour une requête, comme illustré dans les Fig. 14 et Fig. 16, nous pouvons dire à l'optimiseur de toujours utiliser un plan que nous choisissons en cliquant sur le bouton Forcer le plan. C'était une tâche un peu fastidieuse dans les versions précédentes de SQL Server.

Comme vous pouvez le voir sur la Fig. 17, Query Store nous permet de comparer les différents plans associés à une requête en utilisant un certain nombre de métriques.

Fig. 17 Comparaison des plans d'exécution

Encore une fois, nous pouvons utiliser la requête du Listing 8 pour vérifier les plans associés à cet ID de requête à l'aide de DMV. (Reportez-vous à la figure 11)

Liste 8 :Plans associés à la requête 42497

UTILISER WideWorldImportersGOSELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*FROM sys.query_store_plan AS PlJOIN sys.query_store_query AS Qry ON Pl.query_id =Qry.query_idJOIN sys.query_store_query_text AS Txt ON Qry.query_text_id =Txt .query_text_idwhere Qry.query_id=42497 ;

Explorer les variantes

Un autre rapport utile que Query Store nous fournit est celui des requêtes à forte variation. Ce rapport nous montre à quel point les métriques souhaitées sont éloignées pour une requête spécifique sur une période donnée. Ceci est très utile pour l'analyse historique des performances. En utilisant les déclarations de la liste 9, nous générons des données qui peuvent donner une image de ce à quoi ressembleraient les variations. Les étapes de la procédure créent simplement une petite table, puis insèrent des enregistrements en utilisant différentes tailles de lot.

Liste 9 :Plans associés à la requête 42497

use WideWorldImportersgo-- Créer une tablecreate table tableone(ID int identity(1000,1),FirstName varchar(30),LastName varchar(30),CountryCode char(2),HireDate datetime2 default getdate());-- Insérer des enregistrements dans des lots de tailles différentesinsérer dans les valeurs tableone ('Kenneth','Igiri','NG',getdate());GO 10000insérer dans les valeurs tableone ('Kwame','Boateng','GH', getdate());GO 10insert into tableone values ('Philip','Onu','NG',getdate());GO 100000insert into tableone values ('Kwesi','Armah','GH', getdate());GO 100

Query Store nous montre des détails tels que les valeurs minimales et maximales de ces métriques pour des intervalles d'exécution spécifiques de la requête qui nous intéresse. Dans cet exemple, nous constatons que c'est simplement le résultat du nombre de lots par exécution (notez que le sont en fait utilisés pour exécuter l'instruction INSERT). Dans la production, d'autres facteurs pourraient être responsables de telles variations.

Fig. 18 Variations de durée

Fig. 19 Variation des écritures logiques

Fig. 20 Variation des lectures physiques

Conclusion

Dans cet article, nous avons passé en revue l'environnement graphique de SQL Server 2016 Query Store et quelques éléments que nous pouvons en déduire concernant les performances de notre instance (par rapport à SQL) à l'aide de Query Store. Il existe plusieurs articles sur Internet qui montrent des cas d'utilisation encore plus avancés et une explication beaucoup plus approfondie des composants internes. Cet article devrait être utile aux DBA de niveau intermédiaire qui souhaitent prendre une longueur d'avance dans l'utilisation du magasin de requêtes pour l'évaluation/le réglage des performances.

Références

Bonnes pratiques avec le magasin de requêtes
Cristiman, L. (2016) Magasin de requêtes – Paramètres et limites
Surveillance des performances à l'aide du magasin de requêtes
Interroger les vues du catalogue du magasin
Procédures stockées du magasin de requêtes
Query Store - Comment ça marche et comment l'utiliser
Scénarios d'utilisation du magasin de requêtes
Van de Lar, E. (2016) Magasin de requêtes SQL Server 2016 :Forcer les plans d'exécution à l'aide du magasin de requêtes

Outil utile :

dbForge Query Builder pour SQL Server - permet aux utilisateurs de créer rapidement et facilement des requêtes SQL complexes via une interface visuelle intuitive sans écriture manuelle de code.