Чи є total_elapsed_time в DMV sys.dm_exec_requests абсолютно неточним?

Я запускаю SQL Server 2012 і намагаюся зібрати деякі запити для моніторингу за допомогою DMV. Однак, дивлячись на total_elapsed_timeполе в sys.dm_exec_requestsDMV, цифри виглядають далеко. Ось приклад:

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

За моїми підрахунками *, минулий час повинен становити приблизно 349,103 - не 1419,976. Це виключається більш ніж в 4 рази.

_{* Від різниці, в мілісекундах, між поточним часом і початковим часом, тобто
SELECT DATEDIFF(MILLISECOND, '2016-04-07T16:08:14.587', '2016-04-07T16:14:03.690');}

Ось інформація про сервер:

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)

Будь-які ідеї, що може спричинити цю невідповідність?

Існує помилка, яка агрегує час при паралельній операції. Це зафіксовано у 2014 році.

Total_elapsed_time буде правильним для конкретного паралельного запиту в пакеті , поки він не переходить до наступного оператору в пакеті, то total_elapsed_time вибухне на ДОФ.

Приклад

Запустіть це в одному вікні запиту:

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'

Виконайте це за секунду:

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>

Два значення будуть близькими до ідентичних, поки SQL Server не перейде до WAITFORDELAYоператора, тоді ви побачите вибух total_elapsed_time (якщо при цьому перший запит має паралельний план, як це відбувається на моєму сервері).

Пам’ятаю, працював над цим для замовника кілька років тому. Знайдено помилку у внутрішній базі даних (я - консультант з розробників Microsoft Premier), але публічної довідки немає.

Схоже, це також може бути помилка / проблема з DMV. Існує помилка звіту Connect тут такого ж роду неточностей. Запропонований спосіб вирішення

GETDATE() - sys.dm_exec_requests.start_time

замість total_elapsed_time . Проблема вирішена в SQL Server 2014. Щоб процитувати коментар до елемента Connect від "Nathan (MSFT)":

Проблема з sys.dm_exec_requests.total_elapsed_time не характерна для RESTOREоперацій; це також спостерігалося з UPDATE STATISTICS. Ця проблема не буде вирішена в SQL Server 2008 R2. [...] Проблема вирішена в SQL Server 2014.

Я перевірив пару серверів, і на тлі запитів спостерігався затримка близько 14-х протягом 2 місяців.

Однак, осторонь, єдина суттєва різниця, яку я бачу в інших запитах, полягає в тому, де павук перейшов у стан СЛІП. Я підозрюю, що ця величина не збільшується, перебуваючи в такому стані; але я не зміг змусити запросити SLEEPING, щоб перевірити його. (WAITFOR переходить до зупиненого, а не до сну).

Можуть бути й інші причини, але я ще не знайшов. Ви можете виключити цей спосіб, відстежуючи свій запит, щоб переконатися, що він не переходить у стан SLEEPING.