Là Total_elapsed_time trong DMV sys.dm_exec_Vquests hoàn toàn không chính xác?

Tôi đang chạy SQL Server 2012 và đang cố gắng kết hợp một số truy vấn để theo dõi bằng DMV. Tuy nhiên, khi nhìn vào total_elapsed_timetrường trong sys.dm_exec_requestsDMV, các con số có vẻ không ổn. Đây là một ví dụ:

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

Theo tính toán của tôi *, thời gian trôi qua sẽ vào khoảng 349.103 - chứ không phải 1.419.976. Đó là bởi hơn 4 nhân tố.

_{* Từ sự khác biệt, tính bằng mili giây, giữa thời gian hiện tại và start_time tức là
SELECT DATEDIFF(MILLISECOND, '2016-04-07T16:08:14.587', '2016-04-07T16:14:03.690');}

Đây là thông tin máy chủ:

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)

Bất kỳ ý tưởng những gì có thể gây ra sự khác biệt này?

Có một lỗi tổng hợp thời gian trong một hoạt động song song. Điều này được cố định vào năm 2014.

Các total_elapsed_time sẽ được chính xác cho một truy vấn song song cụ thể trong một đợt cho đến khi nó chuyển sang câu lệnh tiếp theo trong hàng loạt, thì total_elapsed_time sẽ nổ bởi DOP.

Thí dụ

Chạy cái này trong một cửa sổ truy vấn:

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'

Chạy cái này trong một giây:

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>

Hai giá trị sẽ gần giống nhau cho đến khi SQL Server di chuyển đến WAITFORDELAYcâu lệnh, sau đó bạn sẽ thấy phát nổ Total_elapsed_time (giả sử truy vấn đầu tiên có kế hoạch song song như trên máy chủ của tôi).

Tôi nhớ làm việc này cho một khách hàng vài năm trước. Đã tìm thấy lỗi trong cơ sở dữ liệu nội bộ (Tôi là Nhà tư vấn dành cho nhà phát triển của Microsoft Premier), nhưng không có tài liệu tham khảo công khai.

Có vẻ như nó cũng có thể là một lỗi / vấn đề với DMV. Có báo cáo lỗi Connect ở đây cùng loại không chính xác. Cách giải quyết được đề xuất là sử dụng

GETDATE() - sys.dm_exec_requests.start_time

thay vì Total_elapsed_time . Vấn đề được giải quyết trong SQL Server 2014. Để trích dẫn nhận xét về mục Kết nối bằng "Nathan (MSFT)":

Vấn đề với sys.dm_exec numquests.total_elapsed_time không cụ thể đối với các RESTOREhoạt động; nó cũng đã được quan sát UPDATE STATISTICSlà tốt. Vấn đề này sẽ không được giải quyết trong SQL Server 2008 R2. [...] Vấn đề được giải quyết trong SQL Server 2014.

Tôi đã kiểm tra một vài máy chủ và trên các yêu cầu nền đã quan sát thấy khoảng 14 giây trôi qua trong 2 tháng.

Tuy nhiên, bên cạnh đó, sự khác biệt đáng kể duy nhất tôi có thể thấy đối với các yêu cầu khác là nơi mà spid đã đi vào trạng thái TUYỆT VỜI. Tôi nghi ngờ rằng giá trị này không tăng trong khi ở trạng thái đó; nhưng tôi đã không thể buộc một truy vấn vào SLEEPING để kiểm tra nó. (WAITFOR đi đến trạng thái lơ lửng thay vì ngủ).

Có thể có những nguyên nhân khác nhưng tôi chưa tìm thấy. Bạn có thể loại trừ điều này bằng cách theo dõi truy vấn của mình để đảm bảo nó không chuyển sang trạng thái SLEEPING.