作者是 Brian Moran，电子邮件地址为 savvy@sqlmag.com
问：我尝试使用 SQL Server 事件探查器为我的一个客户优化一个繁忙的 SQL Server 数据库。这个 8GB 的数据库运行在一台 CPU 利用率为 70% 到 80% 的 8 CPU 服务器上。该服务器很快变得没有响应，我必须重新启动服务器。Microsoft Developer Network (MSDN) 支持人员告诉我，事件探查器会给繁忙的 SQL Server 增加沉重的负担。为了优化数据库，我需要查看查询生成的 SQL 文本和读数。如何从一台繁忙的、多处理器的 SQL Server 上收集此信息而又不会使服务器忙过头儿呢？
[@more@] 答：我将事件探查器视为 SQL Server 优化存储中最重要的工具，并几乎每天建设性地使用它。在过去几年中，我已在 100 多个客户站点使用了事件探查器，包括每秒钟执行数万件事务的服务器。只要小心，我从未遇到过无法使用事件探查器的情况。但像任何强大的工具一样，事件探查器也可能引发问题。
首先，要了解事件探查器只是一个 GUI 前端，它调用一系列统称为 SQL 跟踪的功能和过程。在大多数情况下，与直接调用 SQL 跟踪过程相比，使用事件探查器捕获系统信息代价更高。要确保您不错过繁忙服务器上的任何事件，您需要从事件探查器 GUI 中选择服务器过程跟踪数据选项。不过，此选项启动两个单独的跟踪来捕获同一组事件。SQL Server 将一个事件流发送到事件探查器 GUI，将另一个事件流发送到服务器上的本地文件。您担心运行跟踪产生的影响吗？如果担心，您肯定不希望运行两个跟踪！
另一个事件探查器选项使您能够直接写入 SQL Server 表。但是，如果您在乎性能，则不要使用此选项。SQL Server 会将事件探查器捕获的每一个事件写入表中，还会将每一个事件记录在事务日志中，从而给繁忙的服务器增加了巨大的负担。您应该将事件数据捕获到本地文件中，然后使用 fn_trace_gettable() 函数将跟踪数据加载到表中以供分析。或者，您可以将跟踪数据写入网络驱动器，但是我通常能够将跟踪数据写入本地驱动器而不造成其他 I/O 瓶颈。
考虑到性能影响，我很少在繁忙的生产服务器上运行事件探查器，而是使用一系列直接调用 SQL 跟踪过程的自定义过程来停止、启动和控制跟踪。在此解答中，我没有足够的篇幅来解释我的自定义过程。不过，学习如何编写您自己的过程来控制跟踪是相当简单的。您可以使用事件探查器来了解跟踪是如何运行的。首先，启动一个事件探查器实例以删除阻止事件探查器捕获活动的默认筛选器。然后，启动另一个事件探查器实例并创建您希望手动运行的跟踪。第一个事件探查器实例将捕获第二个实例用于执行您的跟踪的过程，并且您将拥有一个用于创建您自己的跟踪过程的良好模型。您还可以直接从事件探查器使用“脚本跟踪”选项通过脚本来管理正在运行的跟踪。
无论您是通过事件探查器运行跟踪，还是通过直接调用 SQL 跟踪运行跟踪，几乎都不会降低性能，除非它们增长得太大、太快。我见过每秒钟增长 20MB 的跟踪文件，它很可能会影响性能。不过，我经常在极繁忙的服务器上运行跟踪，但性能却没有显著地降低，这是因为我将跟踪文件的增长率保持在可管理的级别上。您需要通过实验来判定对于您的特定硬件来说什么情况下跟踪会增长得太大、太快。当我在繁忙的服务器上运行跟踪时，我总是指定一个最大文件大小。如果某个跟踪的增长失控，其大小超过了我设置的最大文件大小限制，则该跟踪将停止。以我的经验，我发现 50MB 是安全的最大大小。如果一个跟踪的代价很大，会降低性能，那么它将在几秒钟之内达到 50MB 的限制。适合您的具体情况的最大大小取决于您的硬件和事务卷。
另一个控制跟踪文件的大小和降低跟踪诱发性能问题的可能性的方法是：只包含您需要的事件和数据列。确定事件列和数据列的适当搭配是一个复杂的话题。有关选择最符合您的需要的事件列和数据列的更多信息，请参阅 Kalen Delaney 于 2001 年 5 月发表的“Tracking Down Event Clues”（跟踪事件线索，InstantDoc ID 20159）和我在 2003 年 4 月发表的文章“Working with Trace Filters”（使用跟踪筛选器，InstantDoc ID 38040）。您还可以通过指定您要捕获的事务的最小 CPU 持续时间来控制跟踪大小。您的大多数事务将很快，运行时间不超过 20 毫秒，因此将最小时间筛选器设置为 20 毫秒可阻止大量向跟踪文件写入的数据，但不会丢失大量重要事件。
关于管理跟踪文件大小，我的最后一点建议是密切注意用户定义的函数 (UDF)，这些函数会创建大量跟踪数据。如果您有一个 SELECT 语句使用 UDF 返回 10,000 行，并且该 UDF 包含 10 个语句，您就会生成 100,000 个跟踪事件。如果 10 个人同时运行该 SELECT 语句，该 UDF 就会生成 100 万个跟踪事件。通常，一旦您确定特定 UDF 不是导致性能问题的原因，您将需要包括跟踪筛选器以消除 UDF 活动。
此 SQL Server 提示由“SQL Server Magazine”（SQL Server 杂志）提供，该杂志是建立一流应用程序的智能指南。
问：我尝试使用 SQL Server 事件探查器为我的一个客户优化一个繁忙的 SQL Server 数据库。这个 8GB 的数据库运行在一台 CPU 利用率为 70% 到 80% 的 8 CPU 服务器上。该服务器很快变得没有响应，我必须重新启动服务器。Microsoft Developer Network (MSDN) 支持人员告诉我，事件探查器会给繁忙的 SQL Server 增加沉重的负担。为了优化数据库，我需要查看查询生成的 SQL 文本和读数。如何从一台繁忙的、多处理器的 SQL Server 上收集此信息而又不会使服务器忙过头儿呢？
[@more@] 答：我将事件探查器视为 SQL Server 优化存储中最重要的工具，并几乎每天建设性地使用它。在过去几年中，我已在 100 多个客户站点使用了事件探查器，包括每秒钟执行数万件事务的服务器。只要小心，我从未遇到过无法使用事件探查器的情况。但像任何强大的工具一样，事件探查器也可能引发问题。
首先，要了解事件探查器只是一个 GUI 前端，它调用一系列统称为 SQL 跟踪的功能和过程。在大多数情况下，与直接调用 SQL 跟踪过程相比，使用事件探查器捕获系统信息代价更高。要确保您不错过繁忙服务器上的任何事件，您需要从事件探查器 GUI 中选择服务器过程跟踪数据选项。不过，此选项启动两个单独的跟踪来捕获同一组事件。SQL Server 将一个事件流发送到事件探查器 GUI，将另一个事件流发送到服务器上的本地文件。您担心运行跟踪产生的影响吗？如果担心，您肯定不希望运行两个跟踪！
另一个事件探查器选项使您能够直接写入 SQL Server 表。但是，如果您在乎性能，则不要使用此选项。SQL Server 会将事件探查器捕获的每一个事件写入表中，还会将每一个事件记录在事务日志中，从而给繁忙的服务器增加了巨大的负担。您应该将事件数据捕获到本地文件中，然后使用 fn_trace_gettable() 函数将跟踪数据加载到表中以供分析。或者，您可以将跟踪数据写入网络驱动器，但是我通常能够将跟踪数据写入本地驱动器而不造成其他 I/O 瓶颈。
考虑到性能影响，我很少在繁忙的生产服务器上运行事件探查器，而是使用一系列直接调用 SQL 跟踪过程的自定义过程来停止、启动和控制跟踪。在此解答中，我没有足够的篇幅来解释我的自定义过程。不过，学习如何编写您自己的过程来控制跟踪是相当简单的。您可以使用事件探查器来了解跟踪是如何运行的。首先，启动一个事件探查器实例以删除阻止事件探查器捕获活动的默认筛选器。然后，启动另一个事件探查器实例并创建您希望手动运行的跟踪。第一个事件探查器实例将捕获第二个实例用于执行您的跟踪的过程，并且您将拥有一个用于创建您自己的跟踪过程的良好模型。您还可以直接从事件探查器使用“脚本跟踪”选项通过脚本来管理正在运行的跟踪。
无论您是通过事件探查器运行跟踪，还是通过直接调用 SQL 跟踪运行跟踪，几乎都不会降低性能，除非它们增长得太大、太快。我见过每秒钟增长 20MB 的跟踪文件，它很可能会影响性能。不过，我经常在极繁忙的服务器上运行跟踪，但性能却没有显著地降低，这是因为我将跟踪文件的增长率保持在可管理的级别上。您需要通过实验来判定对于您的特定硬件来说什么情况下跟踪会增长得太大、太快。当我在繁忙的服务器上运行跟踪时，我总是指定一个最大文件大小。如果某个跟踪的增长失控，其大小超过了我设置的最大文件大小限制，则该跟踪将停止。以我的经验，我发现 50MB 是安全的最大大小。如果一个跟踪的代价很大，会降低性能，那么它将在几秒钟之内达到 50MB 的限制。适合您的具体情况的最大大小取决于您的硬件和事务卷。
另一个控制跟踪文件的大小和降低跟踪诱发性能问题的可能性的方法是：只包含您需要的事件和数据列。确定事件列和数据列的适当搭配是一个复杂的话题。有关选择最符合您的需要的事件列和数据列的更多信息，请参阅 Kalen Delaney 于 2001 年 5 月发表的“Tracking Down Event Clues”（跟踪事件线索，InstantDoc ID 20159）和我在 2003 年 4 月发表的文章“Working with Trace Filters”（使用跟踪筛选器，InstantDoc ID 38040）。您还可以通过指定您要捕获的事务的最小 CPU 持续时间来控制跟踪大小。您的大多数事务将很快，运行时间不超过 20 毫秒，因此将最小时间筛选器设置为 20 毫秒可阻止大量向跟踪文件写入的数据，但不会丢失大量重要事件。
关于管理跟踪文件大小，我的最后一点建议是密切注意用户定义的函数 (UDF)，这些函数会创建大量跟踪数据。如果您有一个 SELECT 语句使用 UDF 返回 10,000 行，并且该 UDF 包含 10 个语句，您就会生成 100,000 个跟踪事件。如果 10 个人同时运行该 SELECT 语句，该 UDF 就会生成 100 万个跟踪事件。通常，一旦您确定特定 UDF 不是导致性能问题的原因，您将需要包括跟踪筛选器以消除 UDF 活动。
此 SQL Server 提示由“SQL Server Magazine”（SQL Server 杂志）提供，该杂志是建立一流应用程序的智能指南。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/66009/viewspace-1043236/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/66009/viewspace-1043236/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
