total_elapsed_time ใน DMV sys.dm_exec_requests ไม่ถูกต้องสมบูรณ์หรือไม่

ฉันกำลังเรียกใช้ SQL Server 2012 และพยายามรวบรวมแบบสอบถามเพื่อตรวจสอบการใช้ DMV อย่างไรก็ตามเมื่อดูที่total_elapsed_timeฟิลด์ในsys.dm_exec_requestsDMV ตัวเลขจะดูออกไป นี่คือตัวอย่าง:

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)

ความคิดเห็นใดที่อาจทำให้เกิดความคลาดเคลื่อนนี้

มีข้อผิดพลาดที่รวมเวลาในการดำเนินการแบบขนาน นี่คือการแก้ไขในปี 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>

ค่าสองค่าจะใกล้เคียงกันจนกระทั่ง SQL Server ย้ายไปที่WAITFORDELAYคำสั่งจากนั้นคุณควรเห็นการระเบิดของtotal_elapsed_time (สมมติว่าแบบสอบถามแรกมีแผนแบบคู่ขนานเหมือนที่ทำบนเซิร์ฟเวอร์ของฉัน)

ฉันจำได้ว่าเคยทำสิ่งนี้กับลูกค้าเมื่อไม่กี่ปีที่ผ่านมา พบข้อบกพร่องในฐานข้อมูลภายใน (ฉันเป็น Microsoft Premier Developer Consultant) แต่ไม่มีการอ้างอิงสาธารณะ

ดูเหมือนว่ามันอาจเป็นข้อผิดพลาด / ปัญหากับ DMV มีรายงานข้อผิดพลาดการเชื่อมต่อที่นี่ของความไม่ถูกต้องแบบเดียวกันนี้ วิธีแก้ปัญหาที่แนะนำคือการใช้

GETDATE() - sys.dm_exec_requests.start_time

แทนการtotal_elapsed_time ปัญหาได้รับการแก้ไขใน SQL Server 2014 หากต้องการอ้างอิงความคิดเห็นในรายการเชื่อมต่อโดย "Nathan (MSFT)":

ปัญหาเกี่ยวกับsys.dm_exec_requests.total_elapsed_timeไม่ได้มีเฉพาะในRESTOREการดำเนินการ มันก็ถูกตั้งข้อสังเกตด้วยUPDATE STATISTICSเช่นกัน ปัญหานี้จะไม่ได้รับการแก้ไขใน SQL Server 2008 R2 [... ] ปัญหาได้รับการแก้ไขใน SQL Server 2014

ฉันได้ตรวจสอบเซิร์ฟเวอร์สองเครื่องและคำขอแบ็กกราวน์สังเกตว่าการดริฟท์ประมาณ 14 วินาทีในช่วง 2 เดือน

อย่างไรก็ตามที่นอกเหนือความแตกต่างอย่างมีนัยสำคัญเท่านั้นที่ฉันสามารถเห็นในการร้องขออื่น ๆ คือที่ spid ได้เข้าสู่สถานะการนอนหลับ ฉันสงสัยว่าค่านี้จะไม่เพิ่มขึ้นในขณะที่อยู่ในสถานะนั้น แต่ฉันไม่สามารถบังคับให้ข้อความค้นหาเข้าสู่โหมดสลีปเพื่อทดสอบได้ (WAITFOR หยุดทำงานแทนที่จะนอนหลับ)

อาจมีสาเหตุอื่น แต่ฉันยังไม่พบเลย คุณสามารถแยกแยะสิ่งนี้ออกมาได้โดยตรวจสอบข้อความค้นหาของคุณเพื่อให้แน่ใจว่าไม่ได้เข้าสู่โหมดสลีป