对性能进行监视和故障排除

  • 10 分钟

监视和故障排除是提供一致性能的关键要素。 Azure SQL 具有与 SQL Server 相同的工具和功能，可用于对性能及其他功能进行监视和故障排除。 这包括动态管理视图 (DMV)、扩展事件和 Azure Monitor 等功能。 还有必要了解如何在 Azure SQL 的各种性能场景中使用这些工具和功能。 这些场景包括高 CPU 利用率或等待资源。

用于监视性能的工具和功能

Azure SQL 在 Azure 生态系统中提供监视和故障排除功能，还提供 SQL Server 附带的熟悉工具。 下列部分简要描述了这些工具。

Azure Monitor

Azure Monitor 是 Azure 生态系统的一部分，其中集成了 Azure SQL 来支持 Azure 指标、警报和日志。 你可在 Azure 门户中直观呈现 Azure Monitor 数据，应用程序可通过 Azure 事件中心或 API 访问此数据。 与 Windows 性能监视器类似，Azure Monitor 可帮助你访问 Azure SQL 的资源使用指标，无需使用 SQL Server 工具。

动态管理视图 (DMV)

Azure SQL 提供与 SQL Server 几乎相同的 DMV 基础结构，但有一些不同之处。 DMV 对性能监视至关重要，因为你可使用标准的 T-SQL 查询来查看关键的 SQL Server 性能数据。 例如，你可查看诸如活动查询、资源使用情况、查询计划和资源等待类型之类的信息。 你将在此单元后面详细了解 Azure SQL 的 DMV。

扩展的事件

Azure SQL 提供与 SQL Server 几乎相同的扩展事件基础结构，但有一些不同之处。 通过扩展事件，你可跟踪为 Azure SQL 提供支持的 SQL Server 中的关键执行事件。 为了提高性能，扩展事件使你可以跟踪单个查询的执行。 你将在本单元的稍后部分详细了解 Azure SQL 的扩展事件。

轻型查询分析

轻型分析是一种高级方法，用于对需要检索正在进行的请求和高价值查询的实际执行计划的方案进行故障排除。 由于开销较低，任何尚未受 CPU 限制的服务器都可以持续运行轻型分析，这使数据库专业人员可以随时了解任何正在运行的执行，例如，在 SQL Server Management Studio (SSMS) 中使用活动监视器或直接查询 sys.dm_exec_query_profiles 或 sys.dm_exec_query_statistics_xml。

可使用轻型查询分析来检查查询计划和活动查询的运行状态。 这是一种关键功能，可在语句运行时为语句调试查询性能。 与使用扩展事件等工具来跟踪查询性能相比，此功能缩短了解决性能问题的时间。 可通过 DMV 访问轻型查询分析，默认情况下，Azure SQL 和 SQL Server 2019 及更新版本都启用了该功能。

查询计划调试功能

在某些情况下，可能需要单个 T-SQL 语句的查询性能的其他详细信息。 T-SQL SET 语句（如 SHOWPLAN 和 STATISTICS）可提供这些详细信息；如同 SQL Server 一样，Azure SQL 也完全支持这些语句。

查询存储

查询存储是存储在用户数据库中的查询的性能执行历史记录。 Azure SQL 默认启用查询存储，该工具用于提供自动计划更正和自动优化等功能。 针对存储的 SQL Server Management Studio (SSMS) 报表可用于 Azure SQL。 可使用这些报表查找资源消耗量最大的查询（包括查询计划差异）和最常见的等待类型，了解资源等待情形。

性能可视化效果

对于 Azure SQL 数据库，你可通过可视化效果将查询存储性能信息集成到 Azure 门户中。 这样一来，对于查询存储，你就能看到与使用 SSMS 等客户端工具时看到的相同的一些信息。 使用 Azure 门户中的“性能概览”和“Query Performance Insight”选项。

DMV 详细信息

多年以来，DMV 一直是使用 SQL Server 监视性能和排查性能问题的驱动力。 SQL Server 的常用 DMV 适用于 Azure SQL，其他一些 DMV 特定于 Azure。

Azure SQL 托管实例

SQL Server 的所有 DMV 都适用于 SQL 托管实例。 像 sys.dm_exec_requests 和 sys.dm_os_wait_stats 这样的关键 DMV 通常用于检查查询性能。

sys.server_resource_stats 系统视图特定于 Azure SQL 托管实例，并会显示历史资源使用情况。 这是一个用于查看资源使用情况的高价值工具，因为你无法直接访问“性能监视器”等操作系统工具。

Azure SQL 数据库

在性能方面所需的大多数常见 DMV（包括 sys.dm_exec_requests 和 sys.dm_os_wait_stats）都可用。 请注意，这些 DMV 仅提供数据库特定的信息，不提供所有数据库中针对逻辑服务器的信息。

sys.dm_db_resource_stats DMV 特定于 Azure SQL 数据库，可使用它查看数据库的资源使用情况历史记录。 使用此 DMV 类似于对托管实例使用 sys.server_resource_stats 的方式。

sys.elastic_pool_resource_stats DMV 类似于 sys.dm_db_resource_stats，但你可以使用它查看弹性池数据库的资源使用情况。

必需的 DMV

要解决 Azure SQL 的某些性能场景，你需要使用以下 DMV：

  • sys.dm_io_virtual_file_stats 非常重要，因为你无法直接访问操作系统指标来了解每个文件的 I/O 性能。
  • sys.dm_os_performance_counters 同时适用于 Azure SQL 数据库和 SQL 托管实例，它可用来查看 SQL Server 常用性能指标。 使用此 DMV 来查看性能监视器中通常会提供的 SQL Server 性能计数器信息。
  • sys.dm_instance_resource_governance 可用于查看托管实例的资源限制。 可以查看此信息来了解预期资源限制是多少，而无需使用 Azure 门户。
  • sys.dm_user_db_resource_governance 让你能够按 Azure SQL 数据库部署的部署选项、服务层级和大小来查看常用资源限制。 可以查看此信息来了解预期资源限制是多少，而无需使用 Azure 门户。

用于获取更深入见解的 DMV

通过这些 DMV 可更深入地了解 Azure SQL 的资源限制和资源治理。 它们的目的并不是用于常见场景，但在深入了解复杂性能问题时可能会很有帮助。 有关这些 DMV 的所有详细信息，请参阅相关文档：

  • sys.dm_user_db_resource_governance_internal（仅限 SQL 托管实例）
  • sys.dm_resource_governor_resource_pools_history_ex
  • sys.dm_resource_governor_workload_groups_history_ex

扩展事件详细信息

扩展事件功能是 SQL Server 的跟踪机制。 Azure SQL 的扩展事件基于 SQL Server 引擎，因此对于 Azure SQL 来说几乎是相同的，但有几个显著区别。 以下部分介绍了这些区别。

适用于 Azure SQL 数据库的扩展事件

可通过创建会话和使用事件、操作和目标来使用 Azure SQL 数据库的扩展事件，就像 SQL Server 一样。 创建扩展事件会话时，请记住以下要点：

  • 支持最常用的事件和操作。
  • 支持文件、ring_buffer 和计数器目标。
  • Azure Blob 存储支持文件目标，因为你无权访问基础操作系统磁盘。

可以使用 SSMS 或 T-SQL 创建和启动会话。 可以使用 SSMS 查看扩展事件会话目标数据或系统函数 sys.fn_xe_file_target_read_file。

注意

不能使用 SSMS 查看 Azure SQL 数据库的活动数据。

必须了解的是，针对会话触发的任何扩展事件都特定于数据库，不应用于整个逻辑服务器。

适用于 Azure SQL 托管实例的扩展事件

你可通过创建会话以及使用事件、操作和目标，就像 SQL Server 一样使用扩展事件 SQL 托管实例。 创建扩展事件会话时，请记住以下要点：

  • 支持所有事件、目标和操作。
  • Azure Blob 存储支持文件目标，因为你无权访问基础操作系统磁盘。
  • 针对 SQL 托管实例添加了一些特定事件，以跟踪特定于实例的管理和执行的事件。

可以使用 SSMS 或 T-SQL 创建和启动会话。 可以使用 SSMS 查看扩展事件会话目标数据或系统函数 sys.fn_xe_file_target_read_file。 SQL Server 和 Azure SQL 托管实例支持 SSMS 查看实时数据的功能。

针对 Azure SQL 的性能场景

若要确定如何应用监视和故障排除性能工具和功能，请务必通过各种场景来了解 Azure SQL 的性能。

常见性能场景

一种用于 SQL Server 性能故障排除的常见方法是检查性能问题是“运行”（高 CPU 使用率）还是“等待”（等待资源）。 下图显示了一个决策树，它用于确定 SQL Server 性能问题是运行还是等待，以及如何使用性能工具来确定原因和解决方案。

运行与等待的关系图。

我们来更深入地了解一下该关系图各个方面的详细信息。

运行与等待

首先，查看资源整体使用情况。 对于标准 SQL Server 部署，可使用各种工具，例如 Windows 中的性能监视器或 Linux 中的 top。 对于 Azure SQL，可以使用以下方法：

  • Azure 门户/PowerShell/警报

    Azure Monitor 提供集成指标来查看 Azure SQL 的资源使用情况。 还可设置警报来查找资源使用情况。

  • sys.dm_db_resource_stats

    对于 Azure SQL 数据库，可以查看此 DMV 以了解数据库部署的 CPU、内存和 I/O 资源使用情况。 此 DMV 每 15 秒拍摄一次此数据的快照。

  • sys.server_resource_stats

    此 DMV 的行为与 sys.dm_db_resource_stats 相同，但它用于查看 SQL 托管实例的资源使用情况来了解 CPU、内存和 I/O。 此 DMV 也是每 15 秒拍摄一次快照。

  • sys.dm_user_db_resource_governance

    对于 Azure SQL 数据库，此 DMV 将返回当前数据库或弹性池中的资源治理机制所使用的实际配置和容量设置。

  • sys.dm_instance_resource_governance

    对于 Azure SQL 托管实例，此 DMV 返回的信息与 sys.dm_user_db_resource_governance 类似，只不过它是关于当前 SQL 托管实例的。

运行

如果确定问题是高 CPU 利用率，则这称为运行场景。 运行场景可能涉及通过编译或执行来消耗资源的查询。 使用以下工具来进一步分析：

  • 查询存储

    使用 SSMS 中的资源消耗量最大报表、查询存储目录视图或是 Azure 门户中的查询性能见解（仅限 Azure SQL 数据库）可获得消耗最多 CPU 资源的查询。

  • sys.dm_exec_requests

    在 Azure SQL 中使用此 DMV 可获取活动查询状态的快照。 查找状态为 RUNNABLE 且等待类型为 SOS_SCHEDULER_YIELD 的查询，了解你是否具有足够多的 CPU 容量。

  • sys.dm_exec_query_stats

    可像查询存储一样使用此 DMV 来查找资源消耗量最大的查询。 请注意，它仅适用于已缓存的查询计划，而查询存储提供了持久的性能历史记录。 此 DMV 还使你可以获得缓存查询的查询计划。

  • sys.dm_exec_procedure_stats

    此 DMV 提供与 sys.dm_exec_query_stats 非常类似的信息，但可在存储过程级别查看性能信息。

    确定查询消耗量最大的查询后，可能必须检查是否有足够多的 CPU 资源来处理工作负载。 可使用轻型查询分析、SET 语句、查询存储或扩展事件跟踪等工具调试查询计划。

等待

如果问题似乎不是 CPU 资源使用率较高造成的，则可能是涉及等待资源的性能问题。 涉及等待资源的场景包括：

  • I/O 等待
  • Lock waits
  • 闩锁等待
  • 缓冲池限制
  • 内存授予
  • 计划缓存逐出

要对等待场景执行分析，通常应查看以下工具：

  • sys.dm_os_wait_stats

    使用此 DMV 可查看数据库或实例的最常见等待类型。 这可指导你根据最常见的等待类型执行下一步操作。

  • sys.dm_exec_requests

    使用此 DMV 查找活动查询的特定等待类型，以查看它们所等待的资源。 这可能是等待来自其他用户的锁定的标准阻塞场景。

  • sys.dm_os_waiting_tasks

    可以使用此 DMV 查找当前正在执行的特定查询的特定任务的等待类型，或许可以发现它花费的时间比正常情况长的原因。 sys.dm_os_waiting_tasks 包含一段时间内 sys.dm_os_wait_stats 聚合的实时等待统计信息。

  • 查询存储

    查询存储提供报表和目录视图，可显示查询计划执行的最常见等待的聚合。 必须了解的是，等待 CPU 相当于运行问题。

提示

可将扩展事件用于任何运行场景或等待场景。 为此，必须设置扩展事件会话来跟踪查询。 这种调试性能问题的方法更高级，可以返回大量信息，代价是比 DMV 更高的性能开销。

特定于 Azure SQL 的场景

某些性能场景（包括运行场景和等待场景）特定于 Azure SQL。 其中包括日志治理、工作线程限制、业务关键服务层遇到的等待，以及特定于超大规模部署的等待。

日志治理

Azure SQL 可使用日志速率治理来强制实施针对事务日志使用的资源限制。 可能需要此强制措施来确保资源限制并满足承诺的 SLA。 以下等待类型可能会使用日志治理：

  • LOG_RATE_GOVERNOR：等待 Azure SQL 数据库
  • POOL_LOG_RATE_GOVERNOR：等待弹性池
  • INSTANCE_LOG_GOVERNOR：等待 Azure SQL 托管实例
  • HADR_THROTTLE_LOG_RATE*：等待业务关键和异地复制延迟

工作线程限制

SQL Server 使用工作线程池，不过会限制最大工作线程数。 具有大量并发用户的应用程序可能会接近为 Azure SQL 数据库和 SQL 托管实例强制实施的工作器限制：

  • Azure SQL 数据库具有基于服务层级和大小的限制。 如果超过此限制，新查询会收到错误。
  • 当前 SQL 托管实例使用 max worker threads，因此超过此限制的工作器可能会遇到 THREADPOOL 等待。

业务关键 HADR 等待

如果使用业务关键服务层级，则可能会意外遇到以下等待类型：

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

即使这些等待可能不会降低应用程序运行速度，你也可能不希望看到它们。 这些等待类型通常是使用 Always On 可用性组所特定的。 业务关键层使用可用性组技术来实现业务关键服务层级的 SLA 和可用性功能，因此这些等待类型是预期类型。 请注意，漫长的等待时间可能表示遇到瓶颈，例如 I/O 延迟或滞后的副本。

超大规模

超大规模体系结构可能会导致一些独特的等待类型，其前缀为 RBIO（可能指示日志治理）。 此外，DMV、目录视图和扩展事件也得到增强，现可显示页服务器读取的指标。

在下一个练习中，你将了解如何运用你在此单元中获得的工具和知识来监视和解决 Azure SQL 的性能问题。