6

我们有一个 SQL 2000 服务器,它有各种各样的作业,在一天中的不同时间,甚至一个月中的不同日子运行。通常,我们只使用 SQL 探查器在很短的时间内运行跟踪以进行性能故障排除,但在这种情况下,这确实不能让我对在一天或一周或一个月的课程。

如何最小化长时间运行的 SQL 跟踪的性能开销?我已经知道:

  • 执行跟踪服务器端 (sp_create_trace),而不是使用 SQL Profiler UI。
  • 跟踪文件,而不是数据库表(这会增加数据库服务器的额外开销)。

我的问题实际上是关于过滤器的。如果我添加一个过滤器以仅记录运行超过特定持续时间或读取的查询,它仍然必须检查服务器上的所有活动以确定是否需要记录它,对吗?因此,即使使用该过滤器,跟踪是否会为已经处于不可接受性能边缘的服务器创建不可接受的开销水平?

4

4 回答 4

2

添加过滤器确实可以最大限度地减少事件收集的开销,并且还可以防止服务器记录您不需要的事务条目。

至于跟踪是否会产生不可接受的开销水平,您只需要对其进行测试并在有其他投诉时停止它。不过,使用该生产跟踪文件获取 DB Tuning Advisor 的提示可以提高每个人明天的性能。

于 2008-11-13T16:11:19.863 回答
2

您实际上不应该让服务器处理跟踪,因为这可能会导致问题:“当服务器处理跟踪时,不会丢弃任何事件 - 即使这意味着牺牲服务器性能来捕获所有事件。而如果 Profiler 正在处理跟踪,如果服务器太忙,它将跳过事件。” (来自 SQL 70-431 考试书籍最佳实践。)

于 2008-11-13T19:28:25.193 回答
2

我发现一篇文章实际上测量了 SQL 分析器会话与服务器端跟踪的性能影响:

http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx

这确实是我的根本问题,如何确保在跟踪期间不会让生产服务器陷入困境。看来,如果你做对了,就会有最小的开销。

于 2008-12-30T15:34:57.977 回答
0

实际上,可以收集比从 Profiler 收集的更详细的测量结果——并在整个实例中 24x7 进行——而不会产生任何开销。这避免了提前弄清楚你需要过滤什么的必要性……这可能很棘手。

完全披露:我为提供此类工具的供应商之一工作……但无论您使用我们的还是其他人的……这可能会让您绕过这里的核心问题。

有关我们工具的更多信息,请点击此处http://bit.ly/aZKerz

于 2010-11-18T17:52:28.267 回答