0

在用于 sp/rpc/stmt 完成事件的 SQL XE 中,如果我们可以包含 IO/网络等待等等待类型,那就太好了。就像我们可以看到 reads/cpu/duration 一样,如果我们还可以获得其他资源等待,我们可以了解为什么 sql 在持续时间/CPU 较高且读取较低的情况下运行缓慢。

4

1 回答 1

0

您实际上可以跟踪查询的等待统计信息,但反过来 - 通过跟踪等待统计信息本身。查看以下代码段和结果图像:

CREATE EVENT SESSION [Wait Statistics] ON SERVER 
ADD EVENT sqlos.wait_info
(
    ACTION(sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text)
    WHERE (             
            opcode = N'End'
            AND duration > 0
         )
),
ADD EVENT sqlos.wait_info_external
(
    ACTION(sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text)
    WHERE ( 
            opcode = N'End'
            AND duration > 0
          )
) 

在此处输入图像描述

在这里,我们捕获了持续时间大于 0 的每个等待的结束时间(这样做是因为此时 SQL Server 知道统计信息的持续时间,因此我们可以将其输出到结果中)。在 ACTION 部分,我们检索数据库名称、导致统计的查询文本和查询的会话 ID。

不过要小心。通过扩展事件(而不是通过收集聚合数据的 sys.dm_os_wait_stats)跟踪等待统计信息可以非常快速地生成大量数据。如果您选择此方法,您应该非常仔细地定义您想要跟踪的等待统计信息以及统计信息的持续时间导致您出现问题的原因。

于 2017-06-13T10:40:43.153 回答