检查 SQL 事件探查器的输出。
在解决性能问题时有效地查看 SQL 事件探查器的数据是非常有用的。最重要的是,要意识到您不必查看捕获的所有内容,而应当有选择地查看。SQL 事件探查器提供了可以帮助您高效地查看已捕获数据的功能。在属性选项卡上(单击文件菜单上的属性),SQL 事件探查器允许您通过删除数据列或事件、按数据列分组(排序)以及应用筛选器来限制显示的数据。您可以检索整个跟踪或只是特定值的特定列(在编辑菜单上单击查找)。还可以将 SQL 事件探查器的数据保存到 SQL Server 表中(在文件菜单上,指向另存为,然后单击跟踪表),然后对它运行 SQL 查询。
注意,应只在以前已保存的跟踪文件上执行筛选。如果在某个活动跟踪上执行这些步骤,由于已经启动跟踪,将会有丢失已捕获数据的危险。首先将活动跟踪保存至某个文件或表(在文件菜单上,单击另存为),然后在继续执行前重新打开此跟踪(在文件菜单上,单击打开)。在处理已保存的跟踪文件时,筛选操作不会永久地删除被筛选出来的数据,它只是不显示这些数据。您可以根据需要添加和删除事件及数据列来帮助进行检索。
在 SQL 事件探查器跟踪文件中检查性能情形时,首先要确定服务器上发生不同类型事件的位置。
按事件类对跟踪进行分组:
a. 在文件菜单上,单击属性。
b. 在数据列选项卡上,使用向上按钮移动组标题下面的事件类,并使用向下按钮删除组标题下面的所有其他列。
c. 单击确定。
按事件类的列进行分组可显示 SQL Server 上正在发生什么类型的事件以及发生频率。在此列中检索下列事件:
SP:RECOMPILE
此事件表示存储过程在执行期间被重新编译。多个重新编译事件表示 SQL Server 在查询编译上(而不是在查询执行上)花费了资源。 有关解决存储过程重新编译问题的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章: 243586(http://support.microsoft.com/kb/243586/)存储过程重新编译的疑难解答
Attention
注意信号表示客户端取消了查询。通常,这是由于下面两个原因之一所至: 用户明确地取消了查询或结了束应用程序。 - 或 - 超出了查询超时。 如果显示注意信号,则可能表示某些查询正在缓慢运行。 有关其他信息,请单击下面的文章编号,以查看 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。
根据具体情况,这些字段的好处可能有所不同,但如果上文中明确提到的字段没有提供答案,则应当对这些字段进行检查。 |