DMV sys.dm_exec_requests içindeki total_elapsed_time tamamen yanlış mı?

SQL Server 2012 çalıştırıyorum ve DMV'leri kullanarak izlemek için bazı sorguları bir araya getirmeye çalışıyorum. Bununla birlikte, DMV'deki total_elapsed_timealana bakarken sys.dm_exec_requests, sayılar çok uzak görünüyor. İşte bir örnek:

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

Hesaplamalarım * ile geçen süre 1.419.976 değil, 349.103 civarında olmalıdır. Bu 4 kat fazla.

_{* Farktan , milisaniye cinsinden, geçerli saat ve başlangıç_ saati arasında yani
SELECT DATEDIFF(MILLISECOND, '2016-04-07T16:08:14.587', '2016-04-07T16:14:03.690');}

Sunucu bilgileri:

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)

Bu tutarsızlığa neden olabilecek herhangi bir fikir var mı?

Paralel işlemde zamanı toplayan bir hata var. Bu 2014 yılında düzeltildi.

Total_elapsed_time o toplu sonraki deyimi geçer kadar toplu belirli paralel sorgu için doğru olacaktır, daha sonra total_elapsed_time DOP ile patlayacak.

Misal

Bunu tek bir sorgu penceresinde çalıştırı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'

Bunu bir saniyede çalıştırın:

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 WAITFORDELAYdeyime hareket edene kadar iki değer aynı olacak , o zaman total_elapsed_time patlamasını görmelisiniz (ilk sorgunun sunucumda olduğu gibi paralel bir planı olduğunu varsayarak).

Birkaç yıl önce bir müşteri için bunun üzerinde çalıştığımı hatırlıyorum. Dahili veritabanındaki hatayı buldum (Microsoft Premier Geliştirici Danışmanıyım), ancak genel başvuru yok.

Görünüşe göre DMV ile ilgili bir hata / sorun da olabilir. Bu tür bir yanlışlık için bir Connect hata raporu var . Önerilen geçici çözüm

GETDATE() - sys.dm_exec_requests.start_time

total_elapsed_time yerine . Sorun SQL Server 2014'te giderilmiştir. "Nathan (MSFT)" tarafından Connect öğesine yorum yapmak için:

Sys.dm_exec_requests.total_elapsed_time ile ilgili sorun RESTOREişlemlere özgü değildir ; ile de gözlemlenmiştir UPDATE STATISTICS. Bu sorun SQL Server 2008 R2'de çözülmeyecektir. [...] Sorun SQL Server 2014'te giderildi.

Birkaç sunucu kontrol ettik ve arka plan istekleri üzerinde 2 ay içinde yaklaşık 14s bir sapma gözlemledi.

Ancak bu bir yana, diğer isteklerde görebildiğim tek önemli fark, örümceğin UYKU durumuna geçmesidir. Bu durumda bu değerin artmadığından şüpheleniyorum; ama SLEEPING içine bir sorguyu test etmek için zorlayamadım. (WAITFOR uyumak yerine askıya alınır).

Başka nedenler olabilir ama henüz bulamadım. SLEEPING durumuna gitmediğinden emin olmak için sorgunuzu izleyerek bunu devre dışı bırakabilirsiniz.