作为开发人员,我经常使用sql事件探查器.它是一个很好的调试工具,用于跟踪我的代码正在执行的操作以及分析性能问题.
但我总是在我的开发环境中使用它,并以一种非常可控的方式使用它.
>启动我的应用程序,并使其进入特定状态
>在探查器上开始跟踪
>对我的应用程序执行特定的操作序列
>停止跟踪并检查结果.
sql事件探查器是否可以在生产环境中实际使用？
我首先担心的是它会降低性能.
我的第二个问题是,因为它正在制作中,所以你并没有触发有趣的动作本身.您必须让探查器长时间运行然后分析结果.结果集会变得太笨重吗？ (占用太多磁盘空间并且太难查询).
有人在生产中使用sql事件探查器吗？
解决方法
使用sql Server Profiler(GUI工具)跟踪生产服务器不是一个好主意.但这取决于负荷.使用服务器端sql跟踪(请参阅
sp_trace_XXX过程)而不是它.我也找到了文章：
Performance Impact: Profiler Tracing vs. Server Side SQL Tracing,
Automating Server Side Tracing in SQL Server
Avoid Causing Problems with Profiler
也许它会感兴趣和有用.
>远程运行Profiler而不是直接在服务器上运行>除非绝对需要,否则避免包括频繁发生的事件(例如Lock：Acquired)>仅包括所需的事件类>指定限制过滤器以减少事件数>避免冗余数据(例如sql：BatchStarting和sql：BatchCompleted)>避免使用Profiler运行大型跟踪;考虑使用服务器端sql Trace>限制服务器端跟踪文件大小并管理空间使用情况
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
