J'exécute SQL Server 2012 et j'essaie de rassembler certaines requêtes pour la surveillance à l'aide des DMV. Cependant, lorsque l'on regarde le total_elapsed_time
champ dans le sys.dm_exec_requests
DMV, les chiffres semblent loin. Voici un exemple:
SELECT
session_id, RunTime = CURRENT_TIMESTAMP,
start_time, total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id = 284;
session_id RunTime start_time total_elapsed_time
284 2016-04-07 16:14:03.690 2016-04-07 16:08:14.587 1419976
D'après mes calculs *, le temps écoulé devrait être d'environ 349 103 - et non 1 419 976. C'est plus d'un facteur 4.
* De la différence, en millisecondes, entre l'heure actuelle et l' heure de début, c'est-à-dire
SELECT DATEDIFF(MILLISECOND, '2016-04-07T16:08:14.587', '2016-04-07T16:14:03.690');
Voici les informations du serveur:
SELECT @@VERSION;
Microsoft SQL Server 2012 - 11.0.5592.0 (X64)
Apr 17 2015 15:18:46
Copyright (c) Microsoft Corporation
Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
Des idées sur ce qui pourrait être à l'origine de cet écart?
sql-server
sql-server-2012
dmv
JoeNahmias
la source
la source
Réponses:
Il y a un bogue qui agrège le temps dans une opération parallèle. Ceci est corrigé en 2014.
Le total_elapsed_time sera correct pour une requête parallèle particulière dans un lot jusqu'à ce qu'il passe à l'instruction suivante dans le lot, puis le total_elapsed_time explosera par le DOP.
Exemple
Exécutez ceci dans une fenêtre de requête:
Exécutez ceci en une seconde:
Les deux valeurs seront presque identiques jusqu'à ce que SQL Server passe à l'
WAITFORDELAY
instruction, alors vous devriez voir l' explosion de total_elapsed_time (en supposant que la première requête a un plan parallèle comme sur mon serveur).Je me souviens avoir travaillé là-dessus pour un client il y a quelques années. Trouvé le bogue dans la base de données interne (je suis consultant Microsoft Premier Developer), mais aucune référence publique.
la source
Il semble que cela pourrait également être un bug / problème avec le DMV. Il y a un bug Connect rapport ici de ce même genre d'inexactitude. La solution de contournement suggérée consiste à utiliser
au lieu de total_elapsed_time . Le problème est résolu dans SQL Server 2014. Pour citer le commentaire sur l'élément Connect par «Nathan (MSFT)»:
la source
J'ai vérifié quelques serveurs et en arrière-plan, les demandes ont observé une dérive d'environ 14 secondes sur 2 mois.
Cependant, à part cela, la seule différence significative que je peux voir sur d'autres demandes est l'endroit où le spid est passé en état SLEEPING. Je soupçonne que cette valeur n'augmente pas dans cet état; mais je n'ai pas pu forcer une requête dans SLEEPING pour la tester. (WAITFOR va suspendu plutôt que de dormir).
Il peut y avoir d'autres causes mais je n'en ai pas encore trouvé. Vous pouvez exclure celui-ci en surveillant votre requête pour vous assurer qu'elle ne passe pas à l'état SLEEPING.
la source