Management Studio 中的查询执行时间分析器。它测量什么？

发布于 2024-09-07 02:56:45 字数 761 浏览 5 评论 0原文

我的生产 SQL Server 位于远程数据中心（并且 Web 服务器位于同一数据中心）。在开发过程中，我们观察到一个特定的视图需要在本地开发 SQL Server 中执行很长时间（大约 60-80 秒），我们对此表示满意。它被提升到生产环境，当我在生产数据库上运行相同的查询时（位于数据中心）从我本地的 Management Studio 中我看到查询运行大约需要 7 分钟 17 秒（可在 Management Studio 的右下角找到）。当我运行探查器时，我看到所花费的时间执行该查询需要 437101 微秒毫秒，~~尽管它在 Management Studio 中显示为 7:17。~~ ，实际上大约是 437101 毫秒。我的 DBA 说，在产品中，视图只需要大约 60 到 80 秒，尽管我从 Profiler 和 Management Studio 看到不同的数字。有人可以告诉我这些持续时间在 Profiler 和 Management Studio 中意味着什么吗？

我的猜测：发送最后一个请求字节和从服务器接收最后一个响应字节之间的持续时间。客户统计如下：客户端处理时间：90393 总执行时间：92221 服务器回复的等待时间：1828

我对探查器上的“持续时间”含义的最佳猜测是“SQL Server（优化引擎解析查询、生成查询计划或使用现有查询计划+从不同的查询获取记录）所花费的时间页）生成结果集，其中不包括数据通过线路传输到客户端所花费的时间”

编辑：我发现这两个时间大致相同（管理工作室与探查器）。它们与我在客户统计数据中看到的时间有何关系？

有人可以进一步阐明这些吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

甜柠檬 2024-09-14 02:56:46

尝试用这个：

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'

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'

回复收藏 0 原文

荒人说梦 2024-09-14 02:56:45

如果我正确理解您的问题，您首先会质疑 Profiler 报告的持续时间与 SSMS 中显示的统计数据之间的差异（一般时间在右下角和/或通过 SET STATISTICS TIME ON）。除此之外，您似乎不相信生产 DBA 的评论，即视图在大约 60 秒的预期持续时间内执行。

首先，从联机丛书中，SSMS 将通过 SET STATISTICS TIME ON 报告回来的统计数据：

“显示毫秒数
需要解析、编译和
执行每条语句。”

您对此很准确。至于 Profiler 中的 Duration，它被描述为：

“持续时间（以微秒为单位）
事件。”

事件”案例（关于 Profiler 中的持续时间）是选择的执行，其中包括向客户端的交付；这在两种情况下都是一致的，

您似乎怀疑地理位置是远程执行查询时持续时间较长的罪魁祸首。您可以通过在一个查询窗口中的视图上执行选择，然后生成另一个查询窗口并检查查询的等待类型来测试这一点：

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;

如果地理位置是，我怀疑您会看到类似 ASYNC_NETWORK_IO 的等待类型。问题 - 否则，如果您正在分析远程执行的查询，那么持续时间将反映您在 SSMS 中看到的时间统计信息（如果您正在使用 Profiler 并发现该情况）。当从与 SQL Server 位于同一数据中心的 Web 服务器之一执行该查询时，该查询的持续时间仍然需要 7 分钟，那么 DBA 就是个大骗子:)。我会使用 Profiler 记录耗时超过 1 分钟的查询，尝试筛选您的视图并取平均值来查看您是否达到了性能目标。

因为没有发布其他答案，所以我担心我在这里偏离了基地 - 但已经晚了，而且我对此很陌生，所以我想我应该尝试一下！

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!

回复收藏 0 原文