例如,分析器可以捕获存储过程中的每个单独的sql语句,它是什么,以及运行等多长时间?
我正在尝试诊断合并复制存储过程,这必须捕获合并代理的完整运行的一部分.似乎不可能抓住性能问题的存储过程并再次运行它,因为在那时它并不慢.
解决方法
此外,如果您在繁忙的系统上并尝试诊断性能问题,则应该小心使用sql事件探查器. sql事件探查器比跟踪文件或使用扩展事件要慢得多. Jonathan Kehayias的这个blog post显示了使用sql事件探查器在系统性能上的90%开销,以及从跟踪到文件的开销约为10%.减少扩展事件.这就是为什么通常建议不要运行sql Profiler本身
虽然这些信息可以通过扩展事件获得,但我建议仍然使用sql Trace(sql Profiler背后的技术),而是追踪到一个文件(如果你想投资学习和使用扩展事件,那么这将是一种方法,未来版本的sql Server sql Trace将会消失,而我们所拥有的只是扩展事件.我还建议您通过“列过滤器”按钮过滤尽可能多的背景噪音,以确保您只捕获必要的内容.您可以使用Profiler工具使用Kevin在其完美答案中描述的步骤设置跟踪,然后从同一GUI中添加过滤器.然后,您可以将跟踪导出为脚本,并在sql Server上运行该脚本,以跟踪不包含数据库或事务日志文件的文件夹上的文件.要导出,您只需设置跟踪,运行它几秒钟,以确保捕获您想要的内容,停止它然后转到菜单栏和文件 – >出口 – >脚本跟踪定义并保存文件.然后在要跟踪的服务器上的新查询窗口中打开该文件.通过查看刚刚创建的脚本中使用的各种存储过程的帮助文章,您可以通过启动here来查看有关您创建的此脚本的选项和定义的更多信息.
如果您有时间并想学习,您还可以阅读有关扩展事件的一些文章,并了解如何捕获信息.当你准备好从那里开始时,Jonathan Kehayias是博客文章的绝佳资源.