SSMS
 sql >> Base de données >  >> Database Tools >> SSMS

Temps d'exécution des requêtes dans Management Studio et profileur. Que mesure-t-il ?

Si je comprends bien votre question, vous vous interrogez d'abord sur la différence entre la durée rapportée par Profiler et les statistiques présentées dans SSMS (soit dans le coin inférieur droit pour le temps général et/ou par SET STATISTICS TIME ON). De plus, vous ne semblez pas convaincu par le commentaire du DBA de production selon lequel la vue s'exécute dans la durée prévue d'environ 60 secondes.

Tout d'abord, à partir de la documentation en ligne, les statistiques que SSMS rapporterait via SET STATISTICS TIME ON :

"Affiche le nombre de millisecondes nécessaires pour analyser, compiler et exécuter chaque instruction."

Vous êtes parfait pour ça. Quant à la durée dans Profiler, elle est décrite comme :

"La durée (en microsecondes) de l'événement."

D'où je suis assis, ces deux devraient être fonctionnellement équivalents (et, comme vous l'avez sûrement remarqué, Profiler signalera en quelques microsecondes si vous allez à l'encontre de SQL 2005 ou version ultérieure). Je dis cela parce que "l'événement" dans ce cas (concernant la durée dans Profiler) est l'exécution de la sélection, qui inclut la livraison au client ; c'est cohérent dans les deux cas.

Il semble que vous soupçonniez que la géographie est le coupable de la longue durée lors de l'exécution de la requête à distance. Cela peut très bien être. Vous pouvez tester cela en exécutant la sélection sur la vue dans une fenêtre de requête, puis en créant une autre fenêtre de requête et en examinant le type d'attente sur la requête :

select
    a.session_id
    ,a.start_time
    ,a.status
    ,a.command
    ,db_name(a.database_id) as database_name
    ,a.blocking_session_id
    ,a.wait_type
    ,a.wait_time
    ,a.cpu_time
    ,a.total_elapsed_time
    ,b.text
from sys.dm_exec_requests a
    cross apply sys.dm_exec_sql_text(a.sql_handle) b
where a.session_id != @@spid;

Je suppose que vous verriez quelque chose comme ASYNC_NETWORK_IO comme type d'attente si la géographie est le problème - sinon, vérifiez ce qui en résulte. Si vous profilez la requête de votre exécution à distance, la durée reflétera les statistiques de temps que vous voyez dans SSMS. TOUTEFOIS, si vous utilisez Profiler et constatez que la durée de cette requête lorsqu'elle est exécutée à partir de l'un des serveurs Web qui se trouve dans le même centre de données que le serveur SQL prend encore 7 minutes, alors le DBA est un gros menteur :). J'utiliserais Profiler pour enregistrer les requêtes qui prennent plus d'une minute, essayer de filtrer votre vue et prendre la moyenne pour voir si vous êtes sur la cible pour les performances.

Parce qu'il n'y a pas d'autres réponses publiées, je crains que je ne sois loin de la base ici - mais il est tard et je suis nouveau dans ce domaine, alors j'ai pensé que j'allais essayer !