web-dev-qa-db-ja.com

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

SQL Server 2012を実行していて、DMVを使用して監視するためにいくつかのクエリをまとめようとしています。ただし、_total_elapsed_time_ DMVの_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,349,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-serversql-server-2012dmv
13
JoeNahmias

並列操作で時間を集計するバグがあります。これは2014年に修正されています。

total_elapsed_timeは、バッチ内の特定の並列クエリに対して、バッチ内の次のステートメントに移動するまで正しく、次にtotal_elapsed_timeがDOPによって爆発します。

例

これを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です）でバグを発見しましたが、パブリックリファレンスはありません。

11
Chad Mattox

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

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で解決されています。

7
James Rhoat

私はいくつかのサーバーをチェックしましたが、バックグラウンドリクエストでは、2か月で約14秒のドリフトが見られました。

それはさておき、他のリクエストで私が見ることができる唯一の大きな違いは、spidがSLEEPING状態になったところです。この状態では、この値は増加しないと思います。しかし、私はそれをテストするためにクエリを強制的にSLEEPINGにすることができませんでした。 （WAITFORは、スリープ状態ではなく一時停止状態になります）。

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

2
Cody Konior