使用SQL Server事件探查器做应用程序的性能分析

核心提示：有关其他信息，请单击下面的文章编号，使用SQL Server事件探查器做应用程序的性能分析(4)，以查看 Microsoft 知识库中相应的文章： 243589 (http://support.microsoft.com/kb/243589/) 如何解决 SQL Server 7.0 或更高版本上查询低性能的问题要帮助

有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 243589 (http://support.microsoft.com/kb/243589/) 如何解决 SQL Server 7.0 或更高版本上查询低性能的问题要帮助确定收到注意信号的查询，请修订此跟踪使其不按任何数据列分组，然后筛选出那些收到信号的系统进程 ID (SPID)（在筛选器选项卡上，设置 SPID = x）。在注意信号最前面的 SQL:StmtStarting、SQL:BatchStarting 或 SP:StmtStarting 事件是收到超时或取消的查询。您可以在事件类列中搜索 Attention 事件，以便容易地找到此事件（在编辑菜单上，单击查找）。
PREPARE SQL 和 EXEC PREPARED SQL

Prepare SQL 事件表示 ODBC、OLE DB 或 DB-Library 应用程序准备了要使用的一个（或多个）Transact-SQL 语句。Exec Prepared SQL 事件则表示应用程序利用了现有的已准备的语句来执行命令。

比较这两种事件出现的次数。理想情况下，应用程序必须一次准备一个 SQL 语句并多次执行此语句。这将在每次执行语句时节约优化器编译新计划的成本。因此，Exec Prepared SQL 事件的数量应大大超过 Prepare SQL 事件的数量。如果 Prepare SQL 事件的数量几乎等于 Exec Prepared SQL 事件的数量，则可能表示应用程序没有很好地利用准备/执行模式。最好不要准备将只执行一次的语句。有关准备 SQL 语句的更多信息，请参见 SQL Server 7.0 联机丛书中的 “准备 SQL 语句”主题。

如果 Exec Prepared SQL 事件的数量没有比 Prepare SQL 事件的数量多出 3 到 5 倍，则应用程序可能没有有效地利用准备/执行模式。 有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 243588 (http://support.microsoft.com/kb/243588/) 特殊查询性能问题的疑难解答
在 SQL Server 2000 中，将消除每个准备/执行中的过多往返次数，因此，3 到 5 的比率并不非常严格。但是，要尝试并多次重复使用准备好的计划，它仍然是个适用的规则。Missing Column Statistics

此事件表示优化器用于生成更好的查询计划的统计信息不可用。这表示查询在所涉及的至少一个表上没有可用的索引。除了没有可用的索引外，SQL Server 甚至没有关于列所涉及的统计数据，因而无法作出明确的查询计划决定。结果是所生成的查询计划可能不是最佳的。如果看到这些事件，请查看所生成的查询和执行计划，并参见下面的 Microsoft 知识库文章，以获得改进查询性能需要采取的步骤： 243589 (http://support.microsoft.com/kb/243589/) 如何解决 SQL Server 7.0 或更高版本上查询低性能的问题
查看 Missing Column Statistics 事件时，请首先重点检查那些与长时间运行的查询相关联的事件。有些事件可能由 SQL Server 通过 autostats 自动生成并解决，可能不需要用户干预。因此，最好的策略是首先重点检查持续时间较长的查询（如下文所示），并注意是否有关联的 Missing Column Statistics 事件。

如果没有看到这些事件类的实例，下一步则要确定时间花在什么地方了。

按持续时间对跟踪输出进行分组：

a. 在文件菜单上，单击属性。

在数据列选项卡上，使用向上按钮移动组标题下面的持续时间，并使用向下按钮删除组标题下面的所有其他列。

c. 在事件选项卡上，将除 TSQL 和 Stored Procedures 以外的所有组删除。

d. 单击确定。根据持续时间进行分组，您可以很容易地看到哪些 SQL 语句、批处理或过程的运行效率最低。非常重要的是，不仅要查看出现问题的时间，而且要获得性能良好时的时间基准以便进行比较。您可以根据启动时间进行筛选，以便在性能良好时将跟踪分为多个部分，在性能降低时将跟踪当作一个单独的部分。查找性能良好时最长持续时间的查询。这些很可能就是问题的根源。如果整个系统的性能下降，甚至是好的查询也可能显示很长的持续时间，这是因为它们正在等候系统资源。

如果只有少量的查询具有较长的持续时间，请参阅下面的 Microsoft 知识库文章： 243589 (http://support.microsoft.com/kb/243589/) 如何解决 SQL Server 7.0 或更高版本上查询低性能的问题如果查看到个别查询持续时间较短，但数量较多，而且性能监视器输出中的 SQL Compilations/sec 计数器（将在下文说明）很高，请参阅下面的 Microsoft 知识库文章： 243588 (http://support.microsoft.com/kb/243588/) 如何特殊查询性能问题的疑难解答检查其余的数据列：

通过查看跟踪数据中的其他数据列，可以进一步深入了解性能问题的本质。下面是要考虑的一些事项：

如果 CPU 使用率很高，请按 CPU 进行分组以便确定哪些查询使用 CPU 的时间最长。在文本列中查询“hash”或“merge”，以便找到哪个查询执行计划正在使用这些联接类型。这些联接类型对 CPU 和内存的占用量比嵌套循环联接的要大，而后者通常为 IO 密集的。

如果磁盘 IO 是瓶颈，请按读取和写入分组。查看应用程序名称、NT 用户名和 SQL 用户名字段可以帮助隔离长时间运行查询的来源。

异常事件的整数数据列将显示返回给客户端的任何错误。通过在 SQL Server 7.0 联机丛书中搜索这些编号，可以找到这些错误信息的内容。

连接 ID 字段可以帮助确保您正在查看指定客户端的同一会话。而 SPID 无法保证这一点，因为用户可能已经断开连接，并且新的用户已经连接并收到相同的 SPID。根据具体情况，这些字段的好处可能有所不同，但如果上文中明确提到的字段没有提供答案，则应当对这些字段进行检查。
3. 检查性能监视器输出。

性能监视器将显示整个系统的瓶颈。它可能会显示 SQL Server 和应用程序都正常运行，但计算机可能会性能下降、缺乏内存或其他资源。或者，某些计数器可能会显示应用程序和 SQL Server 在执行方式上存在的问题。请至少检查下列计数器：

** 对象：Process

计数器：Processor

实例：SQL Server
** 对象：Processor

计数器：%Processor Time

实例：检查每个处理器实例
** 对象：Physical Disk

计数器：Avg.Disk Queue Length

实例：检查每个物理磁盘实例
** 对象：SQL Server:SQL Statistics

计数器：SQL Compilations/sec
查找性能在某一时间范围内从好变差的变化趋势：什么首先增加？是计算机 CPU 被束缚，还是 DISK IO 被束缚？这些信息连同上文中的事件探查器输出，将帮助您缩小问题的范围。较高的 CPU 使用率问题可能表示存在大量的存储过程重新编译、特殊查询编译、或哈希联接及合并联接被密集使用。必须按照上文所引用的文章来确定正确的操作过程。较长的磁盘队列长度可能表示需要更多的系统内存或更好的磁盘子系统。