Est-ce que total_elapsed_time dans DMV sys.dm_exec_requests est complètement inexact?

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_timechamp dans le sys.dm_exec_requestsDMV, 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?

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:

USE AdventureWorks2012
GO
SELECT *
FROM Sales.SalesOrderDetail sod
JOIN Production.Product p ON sod.ProductID = p.ProductID
ORDER BY Style 

waitfor delay '00:00:15'

Exécutez ceci en une seconde:

select 
    DATEDIFF(ms, start_time, getdate()) ActualElapsedTime,
    total_elapsed_time from sys.dm_exec_requests
where session_id = <your session_id for the above batch>

Les deux valeurs seront presque identiques jusqu'à ce que SQL Server passe à l' WAITFORDELAYinstruction, 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.

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

GETDATE() - sys.dm_exec_requests.start_time

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)»:

Le problème avec sys.dm_exec_requests.total_elapsed_time n'est pas spécifique aux RESTOREopérations; il a également été observé avec UPDATE STATISTICS. Ce problème ne sera pas résolu dans SQL Server 2008 R2. [...] Le problème est résolu dans SQL Server 2014.

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.