DMV sys.dm_exec_requests의 total_elapsed_time이 완전히 정확하지 않습니까?

SQL Server 2012를 실행 중이며 DMV를 사용하여 모니터링하기 위해 쿼리를 함께 작성하려고합니다. 그러나 DMV 의 total_elapsed_time필드를 sys.dm_exec_requests살펴보면 숫자가 사라집니다. 예를 들면 다음과 같습니다.

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

내 계산에 따르면 경과 시간은 약 1,419,976이 아닌 약 349,103입니다. 그것은 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은 DOP에 의해 폭발합니다.

예

하나의 쿼리 창에서 이것을 실행하십시오.

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 프리미어 개발자 컨설턴트)에서 버그를 발견했지만 공개 참조는 없습니다.

DMV의 버그 / 문제 일 수도 있습니다. 이 같은 종류의 부정확성에 대한 Connect 버그 보고서가 있습니다 . 제안 된 해결 방법은

GETDATE() - sys.dm_exec_requests.start_time

total_elapsed_time 대신 . 이 문제는 SQL Server 2014에서 해결되었습니다. "Nathan (MSFT)"으로 Connect 항목에 대한 주석을 인용하려면 다음과 같이하십시오.

sys.dm_exec_requests.total_elapsed_time 의 문제 는 RESTORE작업 에만 국한되지 않습니다 . 그것은 또한 관찰되었다 UPDATE STATISTICS. 이 문제는 SQL Server 2008 R2에서 해결되지 않습니다. [...]이 문제는 SQL Server 2014에서 해결되었습니다.

몇 대의 서버를 확인했으며 백그라운드 요청에서 2 개월 동안 약 14 초의 드리프트가 관찰되었습니다.

그러나 다른 요청에서 볼 수있는 유일한 차이점은 spid가 SLEEPING 상태가 된 곳입니다. 그 상태에서는이 값이 증가하지 않는 것 같습니다. 그러나 테스트를 위해 쿼리를 SLEEPING으로 강제 설정할 수 없었습니다. (WAITFOR는 수면이 아니라 일시 중단됩니다).

다른 원인이있을 수 있지만 아직 찾지 못했습니다. 쿼리가 SLEEPING 상태가되지 않도록 쿼리를 모니터링하여이를 배제 할 수 있습니다.