代码之家  ›  专栏  ›  技术社区  ›  BradC

使用过滤器减少SQL跟踪的开销

  •  6
  • BradC  · 技术社区  · 16 年前

    我们有一个SQL 2000服务器,它有各种各样的作业,在一天的不同时间运行,甚至在一个月的不同日子运行。通常,我们只使用SQL profiler在很短的时间内运行跟踪以进行性能故障排除,但在本例中,这并不能很好地全面描述在一天、一周或一个月内针对数据库运行的各种查询。

    如何将长时间运行的SQL跟踪的性能开销降至最低?我已经知道:

    • 执行跟踪服务器端(sp_uu创建_u跟踪),而不是使用SQL探查器UI。
    • 跟踪到文件,而不是数据库表(这会给数据库服务器增加额外的开销)。

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

    4 回复  |  直到 16 年前
        1
  •  2
  •   Gordon Bell    16 年前

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

    至于跟踪是否会产生不可接受的开销,您只需测试它,如果有其他投诉,就停止它。不过,在生产跟踪文件中使用DB Tuning Advisor的提示可以提高明天每个人的性能。

        2
  •  2
  •   Sam    16 年前

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

        3
  •  2
  •   BradC    16 年前

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

    这确实是我的根本问题,如何确保在跟踪过程中不会使生产服务器陷入困境。看来,如果您做得正确,开销就很小。

        4
  •  0
  •   Niraj Dube    14 年前

    实际上,您可以收集比从Profiler收集到的更详细的度量,并在整个实例中全天候执行,而不会产生任何开销。这避免了提前弄清楚需要过滤哪些内容的必要性,这可能会很棘手。

    充分披露:我为一家提供此类工具的供应商工作,但无论您是使用我们的还是其他人的工具,这可能会让您了解这里的核心问题。

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