Является ли 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, а не 1 419 976. Это более чем в 4 раза.

_{* Из разницы в миллисекундах между текущим временем и start_time т.е.
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 Developer), но нет общедоступной ссылки.

Похоже, это также может быть ошибка / проблема с DMV. Существует ошибка отчета Connect здесь такого же рода неточностей. Предложенный обходной путь должен использовать

GETDATE() - sys.dm_exec_requests.start_time

вместо total_elapsed_time . Эта проблема решена в SQL Server 2014. Чтобы процитировать комментарий к элементу Connect с помощью «Натан (MSFT)»:

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

Я проверил пару серверов и на фоне запросов заметил дрейф около 14 секунд за 2 месяца.

Однако, кроме этого, единственное существенное различие, которое я вижу в других запросах, состоит в том, что spid перешел в состояние SLEEPING. Я подозреваю, что это значение не увеличивается, пока находится в этом состоянии; но я не смог заставить запрос в спящий режим, чтобы проверить его. (Официант идет в подвешенном состоянии, а не спать).

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