本文的发布号曾为 CHS224587
概要
本文分步介绍了如何解决 SQL Server 的性能问题。解决性能问题需要使用一系列步骤隔离并确定应用程序运行缓慢的原因。可能的原因包括：
本文介绍了如何确定性能问题的来源。本文还引用了 Microsoft 知识库中的其他文章，这些文章包含特定性能问题的详细信息，可用于其他问题的疑难解答。
在解决 SQL Server 7.0 或更高版本的应用程序性能问题时，SQL 事件探查器是一种非常有效的工具。SQL 事件探查器可以使您轻松地捕获在正常负载下服务器上发生的所有事件，并提供有关这些事件的信息。将 SQL 事件探查器与 Microsoft Windows NT 性能监视器和一些简单的查询配合使用来确定是否发生阻塞，可为您提供解决大多数性能问题所必需的信息。
有关使用 SQL 事件探查器的信息，请参阅 SQL Server 7.0 和 SQL Server 2000 联机丛书。
2. 使用性能监视器捕获 Windows NT 和 SQL Server 计数器。为此，请按照下列步骤操作：
有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
3. 检查阻塞。
要查看是否发生阻塞，请运行 sp_who 系统存储过程：
注意：运行 sp_who 系统存储过程将检查是否存在阻塞。通常情况下，要完整地解决阻塞问题，这些信息还不够。 有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
查找性能在某一时间范围内从好变差的变化趋势：什么首先增加？是计算机 CPU 被束缚，还是 DISK IO 被束缚？这些信息连同上文中的事件探查器输出，将帮助您缩小问题的范围。较高的 CPU 使用率问题可能表示存在大量的存储过程重新编译、特殊查询编译、或哈希联接及合并联接被密集使用。必须按照上文所引用的文章来确定正确的操作过程。较长的磁盘队列长度可能表示需要更多的系统内存或更好的磁盘子系统。
| • | 阻塞。 |
| • | 系统资源争用。 |
| • | 应用程序设计问题。 |
| • | 执行时间较长的一组特殊的查询或存储过程。 |
SQL 事件探查器
在解决 SQL Server 7.0 或更高版本的应用程序性能问题时，SQL 事件探查器是一种非常有效的工具。SQL 事件探查器可以使您轻松地捕获在正常负载下服务器上发生的所有事件，并提供有关这些事件的信息。将 SQL 事件探查器与 Microsoft Windows NT 性能监视器和一些简单的查询配合使用来确定是否发生阻塞，可为您提供解决大多数性能问题所必需的信息。
监视对象
1. 设置 SQL 事件探查器以捕获跟踪。为此，请按照下列步骤操作：| a. | 打开 SQL 事件探查器。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| b. | 在“工具”菜单上，单击“选项”。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| c. | 确保选中了所有事件类和所有数据列选项。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| d. | 单击“确定”。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| e. | 创建一个新的跟踪。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| f. | 在“文件”菜单上，指向“新建”，然后单击“跟踪”。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| g. | 在“常规”选项卡上，指定跟踪名称和捕获数据的文件。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| h. | 在“事件”选项卡上，将下列事件类型添加到跟踪：
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| i. | 如果应用程序收到超时错误、停止响应（挂起）或遇到使有问题的语句永远不能结束运行的其他事件，那么还应包括下列事件：
这将帮助您确保可以看见超时发生时正在执行的语句 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| j. | 在数据列选项卡上，确保包含下面的列： 对于 SQL Server 2000 开始时间
结束时间 LoginSid SPID 事件类 文本数据 整数数据 二进制数据 持续时间 CPU 读取 写入 应用程序名称 NT 用户名 DB 用户名 对于 SQL Server 7.0
开始时间 结束时间 连接 ID SPID 事件类 文本 整数数据 二进制数据 持续时间 CPU 读取 写入 应用程序名称 NT 用户名 SQL 用户名 |
有关使用 SQL 事件探查器的信息，请参阅 SQL Server 7.0 和 SQL Server 2000 联机丛书。
2. 使用性能监视器捕获 Windows NT 和 SQL Server 计数器。为此，请按照下列步骤操作：
| a. | 启动 Windows NT 性能监视器。 |
| b. | 在视图菜单上，单击日志。 |
| c. | 在选项菜单上，单击日志。 |
| d. | 指定文件名和位置以记录性能计数器。您可以适当地调整更新时间间隔。 |
| e. | 在编辑菜单上，单击添加到日志。 |
| f. | 添加所有对象。Windows NT 和 SQL Server 对象。 |
| g. | 要启动日志，请在选项菜单上单击日志，然后单击启动日志按钮。 |
有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
150934 (http://support.microsoft.com/kb/150934/) 如何为 NT 疑难解答创建性能监视器日志
3. 检查阻塞。
要查看是否发生阻塞，请运行 sp_who 系统存储过程：
exec sp_who
此输出将包含 blk 列。查看输出是否有表示阻塞发生的任何非零项。在出现性能下降的全部时间范围内定期执行该过程。注意：运行 sp_who 系统存储过程将检查是否存在阻塞。通常情况下，要完整地解决阻塞问题，这些信息还不够。 有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
251004 (http://support.microsoft.com/kb/251004/) INF：如何监视 SQL Server 7.0 阻塞
在正常负载下运行应用程序
理想情况下，最好在相同时间范围内捕获 SQL 事件探查器、性能监视器和阻塞输出。该时间范围必须包括应用程序的性能由好到差的时间范围。综合考虑该信息将能够帮助您清楚地了解性能下降的位置。解释结果
| 1. | 检查阻塞。 如果 sp_who 输出中的 blk 列非零，则表示系统上发生阻塞。如果进程相互阻塞，那么被阻塞进程的执行时间可能会更长。 有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 224453 (http://support.microsoft.com/kb/224453/) INF：了解和解决 SQL Server 7.0 或 2000 阻塞问题
|
| 2. | 检查 SQL 事件探查器的输出。 在解决性能问题时有效地查看 SQL 事件探查器的数据是非常有用的。最重要的是，要意识到您不必查看捕获的所有内容，而应当有选择地查看。SQL 事件探查器提供了可以帮助您高效地查看已捕获数据的功能。在属性选项卡上（单击文件菜单上的属性），SQL 事件探查器允许您通过删除数据列或事件、按数据列分组（排序）以及应用筛选器来限制显示的数据。您可以检索整个跟踪或只是特定值的特定列（在编辑菜单上单击查找）。还可以将 SQL 事件探查器的数据保存到 SQL Server 表中（在文件菜单上，指向另存为，然后单击跟踪表），然后对它运行 SQL 查询。 注意，应只在以前已保存的跟踪文件上执行筛选。如果在某个活动跟踪上执行这些步骤，由于已经启动跟踪，将会有丢失已捕获数据的危险。首先将活动跟踪保存至某个文件或表（在文件菜单上，单击另存为），然后在继续执行前重新打开此跟踪（在文件菜单上，单击打开）。在处理已保存的跟踪文件时，筛选操作不会永久地删除被筛选出来的数据，它只是不显示这些数据。您可以根据需要添加和删除事件及数据列来帮助进行检索。 在 SQL 事件探查器跟踪文件中检查性能情形时，首先要确定服务器上发生不同类型事件的位置。 按事件类对跟踪进行分组： a. 在文件菜单上，单击属性。
按事件类的列进行分组可显示 SQL Server 上正在发生什么类型的事件以及发生频率。在此列中检索下列事件：b. 在数据列选项卡上，使用向上按钮移动组标题下面的事件类，并使用向下按钮删除组标题下面的所有其他列。 c. 单击确定。 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 事件则表示应用程序利用了现有的已准备的语句来执行命令。
Missing Column Statistics比较这两种事件出现的次数。理想情况下，应用程序必须一次准备一个 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 的比率并不非常严格。但是，要尝试并多次重复使用准备好的计划，它仍然是个适用的规则。 此事件表示优化器用于生成更好的查询计划的统计信息不可用。这表示查询在所涉及的至少一个表上没有可用的索引。除了没有可用的索引外，SQL Server 甚至没有关于列所涉及的统计数据，因而无法作出明确的查询计划决定。结果是所生成的查询计划可能不是最佳的。如果看到这些事件，请查看所生成的查询和执行计划，并参见下面的 Microsoft 知识库文章，以获得改进查询性能需要采取的步骤： 243589 (http://support.microsoft.com/kb/243589/) 如何解决 SQL Server 7.0 或更高版本上查询低性能的问题
查看 Missing Column Statistics 事件时，请首先重点检查那些与长时间运行的查询相关联的事件。有些事件可能由 SQL Server 通过 autostats 自动生成并解决，可能不需要用户干预。因此，最好的策略是首先重点检查持续时间较长的查询（如下文所示），并注意是否有关联的 Missing Column Statistics 事件。 如果没有看到这些事件类的实例，下一步则要确定时间花在什么地方了。 按持续时间对跟踪输出进行分组： a. 在文件菜单上，单击属性。
根据持续时间进行分组，您可以很容易地看到哪些 SQL 语句、批处理或过程的运行效率最低。非常重要的是，不仅要查看出现问题的时间，而且要获得性能良好时的时间基准以便进行比较。您可以根据启动时间进行筛选，以便在性能良好时将跟踪分为多个部分，在性能降低时将跟踪当作一个单独的部分。查找性能良好时最长持续时间的查询。这些很可能就是问题的根源。如果整个系统的性能下降，甚至是好的查询也可能显示很长的持续时间，这是因为它们正在等候系统资源。在数据列选项卡上，使用向上按钮移动组标题下面的持续时间，并使用向下按钮删除组标题下面的所有其他列。 c. 在事件选项卡上，将除 TSQL 和 Stored Procedures 以外的所有组删除。 d. 单击确定。 如果只有少量的查询具有较长的持续时间，请参阅下面的 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 |
