Dans Microsoft SQL Server, comment puis-je obtenir un plan d'exécution de requête pour une requête/procédure stockée?
Il existe différentes méthodes pour obtenir un plan d’exécution, laquelle dépend de votre situation. En règle générale, vous pouvez utiliser SQL Server Management Studio pour obtenir un plan. Toutefois, si, pour une raison quelconque, vous ne pouvez pas exécuter votre requête dans SQL Server Management Studio, il peut être utile de pouvoir obtenir un plan via SQL Server Profiler ou en inspectant. le cache de plan.
SQL Server est livré avec quelques fonctionnalités intéressantes qui rendent très facile la capture d'un plan d'exécution. Assurez-vous simplement que l'élément de menu "Inclure le plan d'exécution réel" (situé dans le menu "Requête") est coché et exécutez votre requête normalement. .
Si vous essayez d'obtenir le plan d'exécution pour les instructions dans une procédure stockée, vous devez exécuter la procédure stockée, comme suit:
exec p_Example 42
Lorsque votre requête est terminée, un onglet supplémentaire intitulé "Plan d'exécution" apparaît dans le volet de résultats. Si vous avez exécuté plusieurs instructions, de nombreux plans peuvent être affichés dans cet onglet.
À partir de là, vous pouvez inspecter le plan d'exécution dans SQL Server Management Studio ou cliquer avec le bouton droit de la souris sur le plan et sélectionner "Enregistrer le plan d'exécution sous ..." pour enregistrer le plan dans un fichier au format XML.
Cette méthode est très similaire à la méthode 1 (en fait, c'est ce que SQL Server Management Studio fait en interne), mais je l'ai incluse par souci d'exhaustivité ou si SQL Server Management Studio n'est pas disponible.
Avant d'exécuter votre requête, exécutez une des instructions suivantes. L’instruction doit être la seule instruction du lot, c’est-à-dire que vous ne pouvez pas exécuter une autre instruction en même temps:
SET SHOWPLAN_TEXT ON
SET SHOWPLAN_ALL ON
SET SHOWPLAN_XML ON
SET STATISTICS PROFILE ON
SET STATISTICS XML ON -- The is the recommended option to use
Ce sont des options de connexion et vous n'avez donc besoin de l'exécuter qu'une fois par connexion. À partir de ce moment, toutes les instructions exécutées seront accompagnées d'un jeu de résultats supplémentaire contenant votre plan d'exécution au format souhaité. Il vous suffit alors d'exécuter votre requête comme vous le feriez normalement. voir le plan.
Une fois que vous avez terminé, vous pouvez désactiver cette option avec la déclaration suivante:
SET <<option>> OFF
À moins que vous n'ayez une préférence marquée, ma recommandation est d'utiliser l'option STATISTICS XML
. Cette option est équivalente à l'option "Inclure le plan d'exécution réel" de SQL Server Management Studio et fournit le plus d'informations dans le format le plus approprié.
SHOWPLAN_TEXT
- Affiche un plan d'exécution estimé basé sur du texte de base, sans exécuter la requêteSHOWPLAN_ALL
- Affiche un plan d'exécution estimé basé sur le texte avec des estimations de coûts, sans exécuter la requêteSHOWPLAN_XML
- Affiche un plan d'exécution estimé basé sur XML avec des estimations de coûts, sans exécuter la requête. Cela équivaut à l'option "Afficher le plan d'exécution estimé ..." de SQL Server Management Studio.STATISTICS PROFILE
- Exécute la requête et affiche un plan d'exécution réel basé sur du texte.STATISTICS XML
- Exécute la requête et affiche un plan d'exécution réel basé sur XML. Cela équivaut à l'option "Inclure le plan d'exécution réel" dans SQL Server Management Studio.Si vous ne pouvez pas exécuter votre requête directement (ou si votre requête ne s'exécute pas lentement lorsque vous l'exécutez directement (rappelez-vous que nous voulons un plan de la requête qui fonctionne mal), vous pouvez capturer un plan à l'aide d'une trace SQL Server Profiler. L'idée est d'exécuter votre requête lorsqu'une trace qui capture l'un des événements "Showplan" est en cours d'exécution.
Notez qu'en fonction de la charge, vous pouvez utiliser cette méthode dans un environnement de production, mais vous devez évidemment faire preuve de prudence. Les mécanismes de profilage de SQL Server sont conçus pour minimiser l'impact sur la base de données, mais cela ne signifie pas qu'il n'y aura pas d'impact sur les performances . Vous pouvez également rencontrer des difficultés pour filtrer et identifier le plan correct dans votre trace si votre base de données est fortement utilisée. Vous devez évidemment vérifier auprès de votre administrateur de base de données pour savoir s'il est heureux que vous le fassiez dans sa précieuse base de données!
Le plan que vous obtenez équivaut à l'option "Inclure le plan d'exécution réel" de SQL Server Management Studio.
Si vous ne pouvez pas exécuter directement votre requête ni capturer une trace de profileur, vous pouvez toujours obtenir un plan estimé en inspectant le cache du plan de requête SQL.
Nous inspectons le cache de plan en interrogeant SQL Server DMVs . Vous trouverez ci-dessous une requête de base répertoriant tous les plans de requête en cache (au format xml) ainsi que leur texte SQL. Sur la plupart des bases de données, vous devrez également ajouter des clauses de filtrage supplémentaires pour filtrer les résultats en fonction des plans qui vous intéressent.
SELECT UseCounts, Cacheobjtype, Objtype, TEXT, query_plan
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
Exécutez cette requête et cliquez sur le plan XML pour ouvrir le plan dans une nouvelle fenêtre. Cliquez avec le bouton droit de la souris et sélectionnez "Enregistrer le plan d'exécution sous ..." pour enregistrer le plan dans un fichier au format XML.
Parce qu'il y a tellement de facteurs en jeu (allant du schéma de table et d'index aux données stockées et aux statistiques de table), vous devriez toujours essayer d'obtenir un plan d’exécution de la base de données qui vous intéresse (normalement celle qui rencontre un problème de performances).
Vous ne pouvez pas capturer un plan d'exécution pour les procédures stockées chiffrées.
Un plan d'exécution réel est un plan dans lequel SQL Server exécute la requête, alors qu'un plan d'exécution estimé SQL Server détermine ce qu'il ( ferait sans exécuter la requête. Bien que logiquement équivalent, un plan d'exécution réel est beaucoup plus utile car il contient des informations et des statistiques supplémentaires sur ce qui s'est réellement passé lors de l'exécution de la requête. Cela est essentiel pour diagnostiquer les problèmes pour lesquels les estimations des serveurs SQL sont fausses (par exemple, lorsque les statistiques sont obsolètes).
C’est un sujet digne d’un livre (libre) livre à part entière.
En plus de la réponse complète déjà affichée, il est parfois utile de pouvoir accéder au plan d'exécution par programme pour extraire des informations. Exemple de code pour cela est ci-dessous.
DECLARE @TraceID INT
EXEC StartCapture @@SPID, @TraceID OUTPUT
EXEC sp_help 'sys.objects' /*<-- Call your stored proc of interest here.*/
EXEC StopCapture @TraceID
StartCapture
DéfinitionCREATE PROCEDURE StartCapture
@Spid INT,
@TraceID INT OUTPUT
AS
DECLARE @maxfilesize BIGINT = 5
DECLARE @filepath NVARCHAR(200) = N'C:\trace_' + LEFT(NEWID(),36)
EXEC sp_trace_create @TraceID OUTPUT, 0, @filepath, @maxfilesize, NULL
exec sp_trace_setevent @TraceID, 122, 1, 1
exec sp_trace_setevent @TraceID, 122, 22, 1
exec sp_trace_setevent @TraceID, 122, 34, 1
exec sp_trace_setevent @TraceID, 122, 51, 1
exec sp_trace_setevent @TraceID, 122, 12, 1
-- filter for spid
EXEC sp_trace_setfilter @TraceID, 12, 0, 0, @Spid
-- start the trace
EXEC sp_trace_setstatus @TraceID, 1
StopCapture
DéfinitionCREATE PROCEDURE StopCapture
@TraceID INT
AS
WITH XMLNAMESPACES ('http://schemas.Microsoft.com/sqlserver/2004/07/showplan' as sql),
CTE
as (SELECT CAST(TextData AS VARCHAR(MAX)) AS TextData,
ObjectID,
ObjectName,
EventSequence,
/*costs accumulate up the tree so the MAX should be the root*/
MAX(EstimatedTotalSubtreeCost) AS EstimatedTotalSubtreeCost
FROM fn_trace_getinfo(@TraceID) fn
CROSS APPLY fn_trace_gettable(CAST(value AS NVARCHAR(200)), 1)
CROSS APPLY (SELECT CAST(TextData AS XML) AS xPlan) x
CROSS APPLY (SELECT T.relop.value('@EstimatedTotalSubtreeCost',
'float') AS EstimatedTotalSubtreeCost
FROM xPlan.nodes('//sql:RelOp') T(relop)) ca
WHERE property = 2
AND TextData IS NOT NULL
AND ObjectName not in ( 'StopCapture', 'fn_trace_getinfo' )
GROUP BY CAST(TextData AS VARCHAR(MAX)),
ObjectID,
ObjectName,
EventSequence)
SELECT ObjectName,
SUM(EstimatedTotalSubtreeCost) AS EstimatedTotalSubtreeCost
FROM CTE
GROUP BY ObjectID,
ObjectName
-- Stop the trace
EXEC sp_trace_setstatus @TraceID, 0
-- Close and delete the trace
EXEC sp_trace_setstatus @TraceID, 2
GO
En supposant que vous utilisez Microsoft SQL Server Management Studio
Outre les méthodes décrites dans les réponses précédentes, vous pouvez également utiliser un visualiseur de plan d’exécution gratuit et un outil d’optimisation des requêtes ApexSQL Plan (que j’ai rencontré récemment).
Vous pouvez installer et intégrer ApexSQL Plan dans SQL Server Management Studio afin que les plans d'exécution puissent être visualisés directement à partir de SSMS.
Affichage des plans d'exécution estimés dans ApexSQL Plan
Affichage des plans d'exécution réels dans ApexSQL Plan
Pour afficher le plan d'exécution réel d'une requête, continuez à partir de la 2e étape mentionnée précédemment. Maintenant, une fois le plan estimé affiché, cliquez sur le bouton "Réel" dans la barre d'outils principale dans Plan ApexSQL.
Une fois que le bouton "Réel" est cliqué, le plan d'exécution réel sera affiché avec un aperçu détaillé des paramètres de coût ainsi que d'autres données du plan d'exécution.
Pour plus d’informations sur l’affichage des plans d’exécution, cliquez sur ce lien .
Mon outil préféré pour obtenir et analyser en profondeur les plans d'exécution des requêtes est Explorateur de plans SQL Sentry . SSMS est beaucoup plus convivial, pratique et complet pour l'analyse et la visualisation détaillées des plans d'exécution.
Voici un exemple de capture d’écran pour vous donner une idée de la fonctionnalité offerte par l’outil:
Ce n'est qu'une des vues disponibles dans l'outil. Notez un ensemble d'onglets au bas de la fenêtre de l'application, qui vous permet d'obtenir différents types de représentation de votre plan d'exécution ainsi que des informations supplémentaires utiles.
De plus, je n'ai pas remarqué de limitation de son édition gratuite qui empêche son utilisation quotidienne ou vous oblige à acheter la version Pro éventuellement. Donc, si vous préférez vous en tenir à l'édition gratuite, rien ne vous en empêche.
MISE À JOUR: (Merci à Martin Smith ) Plan Explorer est maintenant gratuit! Voir http://www.sqlsentry.com/products/plan-Explorer/sql-server-query-view pour plus de détails.
Les plans de requête peuvent être obtenus à partir d'une session d'événements étendus via l'événement query_post_execution_showplan
. Voici un exemple de session XEvent:
/*
Generated via "Query Detail Tracking" template.
*/
CREATE EVENT SESSION [GetExecutionPlan] ON SERVER
ADD EVENT sqlserver.query_post_execution_showplan(
ACTION(package0.event_sequence,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack)),
/* Remove any of the following events (or include additional events) as desired. */
ADD EVENT sqlserver.error_reported(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack)
WHERE ([package0].[greater_than_uint64]([sqlserver].[database_id],(4)) AND [package0].[equal_boolean]([sqlserver].[is_system],(0)))),
ADD EVENT sqlserver.module_end(SET collect_statement=(1)
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack)
WHERE ([package0].[greater_than_uint64]([sqlserver].[database_id],(4)) AND [package0].[equal_boolean]([sqlserver].[is_system],(0)))),
ADD EVENT sqlserver.rpc_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack)
WHERE ([package0].[greater_than_uint64]([sqlserver].[database_id],(4)) AND [package0].[equal_boolean]([sqlserver].[is_system],(0)))),
ADD EVENT sqlserver.sp_statement_completed(SET collect_object_name=(1)
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack)
WHERE ([package0].[greater_than_uint64]([sqlserver].[database_id],(4)) AND [package0].[equal_boolean]([sqlserver].[is_system],(0)))),
ADD EVENT sqlserver.sql_batch_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack)
WHERE ([package0].[greater_than_uint64]([sqlserver].[database_id],(4)) AND [package0].[equal_boolean]([sqlserver].[is_system],(0)))),
ADD EVENT sqlserver.sql_statement_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack)
WHERE ([package0].[greater_than_uint64]([sqlserver].[database_id],(4)) AND [package0].[equal_boolean]([sqlserver].[is_system],(0))))
ADD TARGET package0.ring_buffer
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=OFF)
GO
Une fois la session créée, (dans SSMS), accédez à l’explorateur d’objets et allez dans Gestion | Événements étendus | Sessions. Cliquez-droit sur la session "GetExecutionPlan" et démarrez-la. Cliquez à nouveau dessus avec le bouton droit de la souris et sélectionnez "Regarder les données en direct".
Ensuite, ouvrez une nouvelle fenêtre de requête et exécutez une ou plusieurs requêtes. En voici un pour AdventureWorks:
USE AdventureWorks;
GO
SELECT p.Name AS ProductName,
NonDiscountSales = (OrderQty * UnitPrice),
Discounts = ((OrderQty * UnitPrice) * UnitPriceDiscount)
FROM Production.Product AS p
INNER JOIN Sales.SalesOrderDetail AS sod
ON p.ProductID = sod.ProductID
ORDER BY ProductName DESC;
GO
Après quelques instants, vous devriez voir des résultats dans l'onglet "GetExecutionPlan: Live Data". Cliquez sur l'un des événements query_post_execution_showplan dans la grille, puis cliquez sur l'onglet "Plan de requête" sous la grille. Cela devrait ressembler à ceci:
EDIT: le code XEvent et la capture d'écran ont été générés à partir de SQL/SSMS 2012 w/SP2. Si vous utilisez SQL 2008/R2, vous pourriez pouvoir ajuster le script pour le faire fonctionner. Mais cette version ne possède pas d'interface graphique, vous devez donc extraire le XML de showplan, l'enregistrer en tant que fichier * .sqlplan et l'ouvrir dans SSMS. C'est encombrant. XEvents n'existait pas dans SQL 2005 ou une version antérieure. Donc, si vous n'êtes pas sur SQL 2012 ou plus tard, je suggérerais fortement l'une des autres réponses postées ici.
À partir de SQL Server 2016+, la fonctionnalité Query Store a été introduite pour surveiller les performances. Il fournit des informations sur le choix et les performances du plan de requête. Ce n’est pas un remplacement complet des événements de trace ou étendus, mais comme il évolue de version en version, nous pourrions obtenir un magasin de requêtes entièrement fonctionnel dans les versions futures de SQL Server. Le flux principal de Query Store
Activation du magasin de requêtes : le magasin de requêtes fonctionne au niveau de la base de données sur le serveur.
tempdb
.
sys.database_query_store_options
(Transact-SQL)
Collecter des informations dans le Query Store : Nous collectons toutes les informations disponibles dans les trois magasins à l'aide de Query Store DMV (Data Management Views).
Magasin de plan de requête: Persistance des informations du plan d'exécution. Il est responsable de la capture de toutes les informations liées à la compilation de la requête.
sys.query_store_query
(Transact-SQL)sys.query_store_plan
(Transact-SQL)sys.query_store_query_text
(Transact-SQL )
Magasin de statistiques d'exécution: Persistance des informations sur les statistiques d'exécution et il s'agit probablement du magasin le plus fréquemment mis à jour. Ces statistiques représentent les données d'exécution de la requête.
sys.query_store_runtime_stats
(Transact-SQL)
Stockage des statistiques d’attente de requête: Persistance et capture des informations de statistiques d’attente.
sys.query_store_wait_stats
(Transact-SQL)
REMARQUE: Le magasin de statistiques sur les requêtes en attente est disponible uniquement dans SQL Server 2017+
Comme avec SQL Server Management Studio (déjà expliqué), il est également possible avec Datagrip comme expliqué ici .
- Cliquez avec le bouton droit de la souris sur une instruction SQL et sélectionnez Expliquer le plan.
- Dans le volet de sortie, cliquez sur Plan.
- Par défaut, vous voyez l'arborescence de la requête. Pour voir le plan de requête, cliquez sur l'icône Afficher la visualisation ou appuyez sur Ctrl + Maj + Alt + U.
Voici une chose importante à savoir en plus de tout ce qui a été dit auparavant.
Les plans de requête sont souvent trop complexes pour être représentés par le type de colonne XML intégré qui comporte une limite de 127 niveaux d'éléments imbriqués. C’est l’une des raisons pour lesquelles sys.dm_exec_query_plan peut renvoyer NULL
ou même générer une erreur dans les versions antérieures de MS SQL. Il est donc généralement plus sûr d’utiliser sys.dm_exec_text_query_plan = à la place. Ce dernier offre également une fonctionnalité supplémentaire intéressante consistant à sélectionner un plan pour un relevé particulier plutôt que le lot complet. Voici comment vous l'utilisez pour afficher les plans des instructions en cours d'exécution:
SELECT p.query_plan
FROM sys.dm_exec_requests AS r
OUTER APPLY sys.dm_exec_text_query_plan(
r.plan_handle,
r.statement_start_offset,
r.statement_end_offset) AS p
La colonne de texte dans la table résultante n’est cependant pas très pratique comparée à une colonne XML. Pour pouvoir cliquer sur le résultat à ouvrir dans un onglet séparé en tant que diagramme, sans devoir sauvegarder son contenu dans un fichier, vous pouvez utiliser un petit truc (souvenez-vous que vous ne pouvez pas simplement utiliser CAST(... AS XML)
), bien que ne fonctionnera que pour une seule ligne:
SELECT Tag = 1, Parent = NULL, [ShowPlanXML!1!!XMLTEXT] = query_plan
FROM sys.dm_exec_text_query_plan(
-- set these variables or copy values
-- from the results of the above query
@plan_handle,
@statement_start_offset,
@statement_end_offset)
FOR XML EXPLICIT
L'explication du plan d'exécution peut être très détaillée et prendre beaucoup de temps de lecture, mais en résumé, si vous utilisez 'expliquer' avant la requête, vous obtiendrez de nombreuses informations, notamment sur les parties exécutées en premier. si vous voulez lire un peu plus de détails à ce sujet, j'ai compilé un petit blog à ce sujet qui vous oriente également vers les bonnes références. https://medium.com/swlh/jetbrains-datagrip-explain-plan-ac406772c47