web-dev-qa-db-fra.com

Collectez le temps d'exécution des requêtes SQL Server en secondes

J'essaie de trouver un moyen de collecter les temps de réponse aux requêtes SQL Server au cours des deux derniers jours, par exemple. Existe-t-il un moyen d'y parvenir? Je sais qu'il existe des DMV de statistiques de requête, mais je ne semble pas atteindre ce dont j'avais besoin. Je n'ai pas accès au magasin de requêtes et je ne peux donc pas l'utiliser pour le moment non plus.

Je recherche le temps de réponse aux requêtes de SQL Server car j'ai des gens qui blâment le serveur SQL mais je ne vois aucune pression de mémoire/pression de processeur ou aucun goulot d'étranglement. Par conséquent, essayer maintenant d'obtenir les temps de réponse pour les requêtes s'est exécuté sur le serveur.

Merci

sql-serversql-server-2016
4
william345

Il existe en effet plusieurs méthodes.

Magasin de requêtes

Puisque vous avez SQL Server 2016, puis-je recommander Query Store? Vous pouvez l'activer par base de données à partir du menu "propriétés" dans SSMS, ou en exécutant quelque chose de similaire au script suivant:

USE [master]
GO
ALTER DATABASE [TestDB] SET QUERY_STORE = ON
GO
ALTER DATABASE [TestDB] SET QUERY_STORE (OPERATION_MODE = READ_WRITE, QUERY_CAPTURE_MODE = AUTO)
GO

Une fois activé, vous pouvez consulter les détails des performances des requêtes.

SSMS view:

Gotchas: Juste avertissement - l'activation de Query Store effacera le cache du plan! Query Store, en tant que fonctionnalité plus récente, peut avoir certaines bizarreries. J'ai parcouru plusieurs moi-même. En ce qui concerne les performances, je le vois utilisé dans des environnements avec 20 000 lots/s et seulement quelques pour cent de surcharge du processeur.

DMV

Une autre option consiste à utiliser les dmvs. Celui que vous recherchez dans ce cas est sys.dm_exec_query_stats, en particulier les colonnes "elapsed_time". Voici une requête pour examiner les requêtes récentes de longue durée.

SELECT TOP 50
st.text,
SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,  
    ((CASE statement_end_offset   
        WHEN -1 THEN DATALENGTH(st.text)  
        ELSE qs.statement_end_offset 
    END - qs.statement_start_offset)/2) + 1
) AS statement_text,
qp.query_plan,
qs.execution_count,
qs.last_execution_time,
qs.last_worker_time/1000000.0 AS last_worker_time_s, --this is CPU time
qs.last_elapsed_time/1000000.0 AS last_elapsed_time_s --this is clock time
FROM sys.dm_exec_query_stats qs  
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st 
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE last_execution_time > DATEADD(minute,-5,GETDATE()) --last 5 minutes
ORDER BY qs.last_elapsed_time DESC

Gotchas à garder à l'esprit avec ce dmv est qu'il ne capture pas les requêtes RECOMPILE et qu'il ne capture pas les requêtes annulées ( ce qui se passe avec un timeout de requête de l'application).

SSMS

Enfin, si vous connaissez la requête exacte, vous pouvez l'exécuter dans SSMS et consulter le plan d'exécution réel. Mettez en surbrillance la sélection et regardez la fenêtre des propriétés sur la droite. Vous verrez des informations extrêmement utiles sur le processeur et la durée (en millisecondes). Des informations similaires existent également pour les opérateurs.

Actual Plan

Gotchas avec cette méthode inclut le fait que les requêtes soumises via SSMS ne reflètent pas nécessairement ce qui se passe avec les requêtes d'application. Lien canonique ici.

En bref, je recommande fortement Query Store.

6
Forrest

En plus des excellents conseils ci-dessus, je pourrais suggérer de vérifier les événements prolongés légers.

Vous pouvez vérifier certains des événements et actions de lumière comme décrit ici

En fonction du stockage disponible et du nombre d'événements capturés, vous pouvez obtenir les données requises avec un impact minimal sur les performances.

À la fin, vous devez tester et trouver ce qui est le mieux et dans la plage de performances de votre serveur

1
KASQLDBA