Total_elapsed_time in DMV sys.dm_exec_requests è completamente impreciso?

Sto eseguendo SQL Server 2012 e sto cercando di mettere insieme alcune query per il monitoraggio utilizzando i DMV. Tuttavia, quando si guarda il total_elapsed_timecampo nel sys.dm_exec_requestsDMV, i numeri sembrano lontani. Ecco un esempio:

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

Secondo i miei calcoli *, il tempo trascorso dovrebbe aggirarsi intorno a 349.103 - non 1.419.976. Questo è fuori di oltre un fattore 4.

_{* Dalla differenza, in millisecondi, tra l'ora corrente e l'ora di inizio, ad es
SELECT DATEDIFF(MILLISECOND, '2016-04-07T16:08:14.587', '2016-04-07T16:14:03.690');}

Ecco le informazioni sul server:

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)

Qualche idea su cosa potrebbe causare questa discrepanza?

C'è un bug che aggrega il tempo in un'operazione parallela. Questo è stato risolto nel 2014.

Il total_elapsed_time sarà corretto per una particolare query parallela in un batch finché non passa alla successiva istruzione del batch, allora il total_elapsed_time esplode dalla DOP.

Esempio

Esegui questo in una finestra di query:

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'

Esegui questo in un secondo:

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>

I due valori saranno quasi identici finché SQL Server non si sposta sull'istruzioneWAITFORDELAY , quindi dovresti vedere l' esplosione di total_elapsed_time (supponendo che la prima query abbia un piano parallelo come sul mio server).

Ricordo di aver lavorato su questo per un cliente qualche anno fa. Trovato il bug nel database interno (sono un consulente per sviluppatori Premier Microsoft), ma nessun riferimento pubblico.

Sembra che potrebbe anche essere un bug / problema con il DMV. C'è un rapporto sui bug di Connect qui con questo stesso tipo di inesattezza. La soluzione suggerita è di utilizzare

GETDATE() - sys.dm_exec_requests.start_time

anziché total_elapsed_time . Il problema è stato risolto in SQL Server 2014. Per citare il commento sull'elemento Connect di "Nathan (MSFT)":

Il problema con sys.dm_exec_requests.total_elapsed_time non è specifico per le RESTOREoperazioni; è stato anche osservato con UPDATE STATISTICS. Questo problema non verrà risolto in SQL Server 2008 R2. [...] Il problema è stato risolto in SQL Server 2014.

Ho controllato un paio di server e sulle richieste in background ho osservato una deriva di circa 14 secondi in 2 mesi.

Tuttavia, a parte ciò, l'unica differenza significativa che posso vedere su altre richieste è dove lo spid è entrato in uno stato di SONNO. Sospetto che questo valore non aumenti mentre si trova in quello stato; ma non sono stato in grado di forzare una query in SLEEPING per testarlo. (WAITFOR va sospeso invece di dormire).

Potrebbero esserci altre cause, ma non ho ancora trovato. Puoi escluderlo monitorando la tua query per assicurarti che non passi allo stato SLEEPING.