我的生产SQL Server位于远程数据中心(并且Web服务器位于同一数据中心)。在开发过程中,我们观察到一个特定的视图在我们的本地开发SQL Server中需要很长时间才能执行(大约60-80秒),我们对它很满意。它被提升为生产,当我在Production DB上运行相同的查询时(来自我的本地Management Studio)我看到查询大约需要7分钟,17秒才能运行(可在管理工作室的右下角找到)。当我运行一个分析器时,我看到所花费的时间执行该查询的是437101 microseconds 毫秒,尽管它在管理工作室中显示为7:17。 ,实际上大约是437101毫秒。我的DBA表示,虽然我看到了探查器和管理工作室的不同数字,但是这个视图只需要大约60到80秒。有人可以告诉我这些持续时间在Profiler和管理工作室中意味着什么?
我的猜测:发送最后一个请求字节和从服务器接收最后一个响应字节之间的持续时间。客户统计数据如下: 客户处理时间:90393 总执行时间:92221 服务器回复的等待时间:1828
我最好猜测分析器上的“持续时间”意味着“SQL Server(优化引擎解析查询,生成查询计划或使用现有查询计划+从不同页面获取记录)所花费的时间”结果集,它排除了数据通过电线传输到客户端所花费的时间“
编辑:我发现这两个时间大致相同(管理工作室vs分析器)。它们与我在客户统计中看到的时间有何关联?
有人可以对这些产生更多的关注吗?
答案 0 :(得分:8)
如果我正确理解您的问题,您首先会质疑Profiler报告的持续时间与SSMS中显示的统计数据之间的差异(一般时间的右下角和/或SET STATISTICS TIME ON) 。除此之外,您似乎不相信生产DBA的观点,即视图在预期的持续时间约为60秒内执行。
首先,从联机丛书中,SSMS将通过SET STATISTICS TIME ON报告的静态:
“显示毫秒数 需要解析,编译和 执行每个语句。“
你是这样做的。至于Profiler中的持续时间,它被描述为:
“持续时间(以微秒为单位) 事件“。
从我所在的位置来看,这两个应该在功能上是等价的(并且,我确信您注意到,如果您违反SQL 2005或更高版本,Profiler将以微秒为单位报告)。我这样说是因为这种情况下的“事件”(关于Profiler中的持续时间)是select的执行,包括交付给客户端;这两种情况都是一致的。
您似乎怀疑地理位置是远程执行查询时长时间的罪魁祸首。这很好。您可以通过在一个查询窗口中对视图执行select然后生成另一个查询窗口并查看查询的等待类型来测试:
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分钟的查询,尝试过滤您的视图并获取平均值以查看您是否达到了性能目标。
因为没有其他答案,所以我担心我会离开这里 - 但现在已经很晚了,我是新手,所以我想我会试一试!
答案 1 :(得分:0)
我一直在努力,直到我找到了......
此外,如果您打开查询的“属性”选项卡,您可能会发现一些神奇的“经过时间”可能会给您一些执行时间...... 希望它有所帮助...
答案 2 :(得分:0)
试试这个:
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'