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