主页 / dba / 问题 / 134704
Accepted
JoeNahmias
Asked: 2016-04-08 12:24:54 +0800 CST

DMV sys.dm_exec_requests 中的 total_elapsed_time 是否完全不准确？

  • 772

我正在运行 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

根据我的计算*，经过的时间应该在 349,103 左右，而不是 1,419,976。相差超过 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

3 个回答

  1. Best Answer

    有一个错误会在并行操作中聚合时间。这是在 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>

    WAITFORDELAY在 SQL Server 移动到语句之前，这两个值将接近相同，然后您应该会看到total_elapsed_time爆炸（假设第一个查询有一个并行计划，就像它在我的服务器上一样）。

    我记得几年前曾为一位客户做过这方面的工作。在内部数据库中发现了错误（我是 Microsoft 高级开发顾问），但没有公开参考。

    • 11

  2. 看起来它也可能是 DMV 的错误/问题。这里有一个关于这种不准确的连接错误报告。建议的解决方法是使用

    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

  3. 我检查了几台服务器，在后台请求中观察到 2 个月内漂移了大约 14 秒。

    然而，除此之外，我可以在其他请求上看到的唯一显着差异是 spid 进入 SLEEPING 状态的位置。我怀疑这个值在那个状态下不会增加；但我无法强制查询进入 SLEEPING 以对其进行测试。（WAITFOR 进入暂停状态而不是休眠状态）。

    可能还有其他原因，但我还没有找到任何原因。您可以通过监视您的查询以确保它不会进入 SLEEPING 状态来排除这个问题。

    • 2

相关问题