我们有一个SQL 2000服务器，它具有在一天中的不同时间或甚至一个月中的不同日期运行的各种各样的作业。通常情况下，我们只使用SQL事件探查器在很短的时间内运行踪迹以进行性能故障排除，但在这种情况下，实际上并不能让我很好地了解在数据库上运行的查询类型一天或一周或一个月的过程。使用过滤器减少SQL跟踪的开销
如何最小化长时间运行的SQL跟踪的性能开销？我已经知道：
我的问题真的是关于过滤器。如果我添加一个过滤器来只记录运行超过一定时间或读取的查询，它仍然需要检查服务器上的所有活动以决定是否需要记录它，对吧？因此，即使使用该过滤器，对于已经处于不可接受性能边缘的服务器而言，跟踪是否会造成不可接受的开销水平？
我发现，其实衡量一个SQL事件探查器会话的性能影响VS服务器端跟踪的文章：
http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx
这真的是我的根本问题，如何确保在跟踪过程中不会让我的生产服务器停滞不前。看起来如果你做得对，那么开销很小。
添加过滤器的确最大限度地减少了事件收集的开销，并且还可以防止服务器记录您不需要的事务条目。
至于跟踪是否会造成不可接受的开销水平，你只需要测试一下，如果有额外的投诉就停下来。但是，使用该生产跟踪文件提取DB Tuning Advisor的提示可以提高每个人的性能。
实际上，您不应该让服务器处理跟踪，因为这可能会导致问题：“当服务器处理跟踪时，不会丢弃任何事件 - 即使这意味着牺牲服务器性能来捕获所有事件。处理跟踪，如果服务器太忙，它将跳过事件。“ （从SQL 70-431考试书籍的最佳实践）
实际上，您可以收集比您从Profiler收集到的更详细的测量数据 - 并且在整个实例中全天使用它 - 而不会产生任何开销。这就避免了提前搞清楚你需要过滤的必要性......这可能会很棘手。
完全披露：我为提供此类工具的供应商之一工作......但无论您使用我们的还是其他人的......这可能会让您在这里遇到核心问题。在这里http://bit.ly/aZKerz
因此我们的工具
更多信息，如果我没有看错，从一个单独的机器上运行探查器GUI？这似乎是面对我在那里看到的其他大部分建议。 – BradC 2008-11-13 22:41:32
这就是微软官方培训指南所说的...... – Sam 2008-11-20 18:08:08