我们有一台SQL 2000服务器，它具有各种各样的工作，这些工作在一天中的不同时间运行，甚至在一个月的不同日期运行。通常，我们只使用SQL分析器在很短的时间内运行跟踪以进行性能故障排除，但在这种情况下，这实际上不能让我对通过该数据库对数据库运行的查询类型有一个很好的全面了解。一天，一周或一个月的过程。
如何最小化长时间运行的SQL跟踪的性能开销？我已经知道：
我的问题是关于过滤器。如果我添加一个过滤器只记录运行超过一定持续时间或读取的查询，它仍然必须检查服务器上的所有活动，以决定是否需要记录它，对吧？因此，即使使用该过滤器，跟踪是否会为已经处于不可接受性能边缘的服务器创建不可接受的开销水平？
答案 0 :(得分：2)
添加过滤器可以最大限度地减少事件收集的开销，还可以防止服务器记录您不需要的事务条目。
至于跟踪是否会产生不可接受的开销水平，您只需要测试它并在有其他投诉时停止它。使用该生产跟踪文件获取数据库调优顾问的提示可以改善明天所有人的性能。
答案 1 :(得分：2)
实际上你不应该让服务器处理跟踪，因为这会导致问题：“当服务器处理跟踪时，不会丢弃任何事件 - 即使这意味着牺牲服务器性能来捕获所有事件。而如果Profiler正在处理跟踪，如果服务器太忙，它将跳过事件。“ （来自SQL 70-431考试的最佳实践。）
答案 2 :(得分：2)
我发现了一篇文章，它实际衡量了SQL事件探查器会话与服务器端跟踪的性能影响：
http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx
这确实是我的根本问题，如何确保在跟踪过程中不会让我的生产服务器陷入困境。看起来，如果你做得正确，开销很小。
答案 3 :(得分：0)
实际上可以收集比从Profiler收集的更详细的测量数据 - 并且可以在整个实例中全天候执行 - 而不会产生任何开销。这样就无需提前计算出需要过滤的内容......这可能很棘手。
完全披露：我为提供此类工具的供应商之一工作......但无论您使用我们的还是其他人......这可能会让您解决核心问题。
有关我们工具的更多信息http://bit.ly/aZKerz