Query Execution time in Management Studio & profiler. What does it measure?

微笑、不失礼 提交于 2019-12-05 03:01:40
scottE

If I'm understanding your question correctly, you are first questioning the difference between the Duration reported by Profiler and the statistics presented in SSMS (either in lower right-hand corner for general time and/or by SET STATISTICS TIME ON). In addition to that, you seem to be unconvinced of the production DBA's comment that the view is executing in the expected duration of ~60 seconds.

First, from Books Online, the statics that SSMS would report back via SET STATISTICS TIME ON:

"Displays the number of milliseconds required to parse, compile, and execute each statement."

You're spot-on for this. As for Duration in Profiler, it is described as:

"The duration (in microseconds) of the event."

From where I sit, these two should be functionally equivalent (and, as I'm sure you noticed, Profiler will report in microseconds if your going against SQL 2005 or later). I say this because the "event" in this case (regarding Duration in Profiler) is the execution of the select, which includes delivery to the client; this is consistent in both cases.

It seems you suspect that geography is the culprit to the long duration when executing the query remotely. This very well may be. You can test for this by executing the select on the view in one query window then spawning another query window and reviewing the wait type on the query:

select
    a.session_id
    ,a.start_time
    ,a.status
    ,a.command
    ,db_name(a.database_id) as database_name
    ,a.blocking_session_id
    ,a.wait_type
    ,a.wait_time
    ,a.cpu_time
    ,a.total_elapsed_time
    ,b.text
from sys.dm_exec_requests a
    cross apply sys.dm_exec_sql_text(a.sql_handle) b
where a.session_id != @@spid;

I would suspect that you would see something like ASYNC_NETWORK_IO as the wait type if geography is the problem - otherwise, check out what does come of this. If you're Profiling the query of your remote execution, the Duration will be reflective of the time statistics you see in SSMS. HOWEVER, if you're using Profiler and finding that the duration of this query when executed from one of the web servers that sits in the same data center as the SQL Server is still taking 7 minutes, then the DBA is a big, fat liar :). I would use Profiler to record queries that take longer than 1 minute, try to filter for your view and take the average to see if you're on target for performance.

Because there are no other answers posted, I'm concerned that I'm way off base here - but it's late and I'm new to this so I thought I'd give it a go!

I was struggling with that until i found this...

http://blog.sqlauthority.com/2009/10/01/sql-server-sql-server-management-studio-and-client-statistics/

Also, if you open the Property tab for your query you may find some magical "Elapsed Time" that may give you some execution time... Hope it helps...

Try with this:

DECLARE @time AS DATETIME = CURRENT_TIMESTAMP

-- Your Query

SELECT CAST(DATEDIFF(SECOND, @time, CURRENT_TIMESTAMP) AS VARCHAR)
    + ','
    + CAST(DATEDIFF(MICROSECOND, @time, CURRENT_TIMESTAMP) AS VARCHAR)
    AS 'Execution Time'
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!