Является ли total_elapsed_time в DMV sys.dm_exec_requests полностью неточным?


13

Я использую 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)

Есть идеи, что может быть причиной этого несоответствия?


Ответы:


11

Существует ошибка, которая объединяет время в параллельной операции. Это исправлено в 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), но нет общедоступной ссылки.


7

Похоже, это также может быть ошибка / проблема с 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.


2

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.