sql-server – 了解SQL事件探查器中的读/写次数

发布时间：2020-12-12 07:29:23 所属栏目：MsSql教程来源：网络整理

导读：请参见此SQL Profiler视图中指示的SQL语句.所有这些事件都来自一台忙于长时间运行的客户机,工作了几千行.一行的每次处理大约需要6.5秒,这就是SQL事件探查器显示的注销之间的时间,即使实际的更新语句只需要1毫秒.每次登录/注销都使用相同的SPID.在任何给定的Lo

请参见此SQL Profiler视图中指示的SQL语句.所有这些事件都来自一台忙于长时间运行的客户机,工作了几千行.一行的每次处理大约需要6.5秒,这就是SQL事件探查器显示的注销之间的时间,即使实际的更新语句只需要1毫秒.每次登录/注销都使用相同的SPID.在任何给定的Login和Logout事件之间看到,SQL语句指示读取计数为17,写入计数为0.
然而,Logout事件表明总读数超过200万,写入次数超过10k.我需要进行哪些事件来进行分析以试图找出导致这些读/写的语句,因为我怀疑这些是导致6.5秒延迟的那些事件,但我看不到它们发生了什么？

解决方法

为Audit：Logout事件提供的读/写数字是该连接持续时间的累计总数.这些值本身并没有告诉您任何细节 – 如果您在连接的生命周期内运行10个命令,您将看到该会话中所有10个命令的总数.

要了解细分是什么,您需要查看在启动的Audit：Login事件和结束的Audit：Logout事件之间为同一个SPID记录的SQL：BatchCompleted(或SQL：StmtCompleted)事件.

更新：
看一下图像,看起来有点奇怪(至少对我来说)的是,在每次审计：注销之后,Reads值不会被重置,因此每次它都会被语句的读取次数递增被执行(17).我不确定100％因此该数字将被重置 – 但基本点是该数字是累积的并且可能随着时间的推移而建立起来/一些陈述因此并不一定意味着你有一个沉重的查询命中服务器！

我怀疑审计：退出的读/写数字表现如上所述.但持续时间这个趋势令人反感.看起来持续时间不是累积的.
MSDN的一些描述：

Duration : Amount of time since the user logged in (approximately). Reads: Number of logical read I/Os issued by the user during the connection. Writes: Number of logical write I/Os issued by the user during the connection.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!