DMV sys.dm_exec_requestsのtotal_elapsed_timeは完全に不正確ですか？

13

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)

この矛盾の原因は何ですか？

sql-server sql-server-2012 dmv

— ジョー・ナヒマス
ソース

例

これを1つのクエリウィンドウで実行します。

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ステートメントに移動するまで、2つの値はほぼ同じになり、total_elapsed_timeが爆発するはずです（最初のクエリが私のサーバーと同じように並列プランを持っていると仮定します）。

数年前に顧客のためにこれに取り組んだことを覚えています。内部データベース（私はMicrosoft Premier Developer Consultantです）でバグを見つけましたが、公開されている参照はありません。

— チャド・マトックス
ソース

7

DMVのバグ/問題でもあるようです。この同じ種類の不正確さのConnectバグレポートがここにあります。推奨される回避策は、使用することです

GETDATE() - sys.dm_exec_requests.start_time

total_elapsed_timeの代わりに。この問題はSQL Server 2014で解決されました。「ネイサン（MSFT）」による接続項目に関するコメントを引用するには：

sys.dm_exec_requests.total_elapsed_timeの問題は、RESTORE操作に固有のものではありません。それも同様に観察されてUPDATE STATISTICSいます。この問題は、SQL Server 2008 R2では解決されません。[...]この問題はSQL Server 2014で解決されました。

— ジェームス・ロート
ソース

2

数台のサーバーをチェックしましたが、バックグラウンドで、2か月で約14秒のドリフトがリクエストされました。

ただし、それ以外に、他のリクエストで確認できる唯一の大きな違いは、spidがSLEEPING状態になったことです。この状態では、この値は増加しません。しかし、クエリを強制的にテストしてSLEEPINGにすることはできませんでした。（WAITFORはスリープ状態ではなくサスペンド状態になります）。

他の原因があるかもしれませんが、私はまだ何も見つけていません。クエリを監視して、スリープ状態にならないようにすることで、これを除外できます。

— コーディ・コニオール
ソース