使用 AWR 进行 Exadata 性能诊断

本文和之前的使用 AWR 进行 Exadata 性能诊断是非常类似的，理论部分几乎一样，但案例部分是不同的，其价值也在于此。前文是基于Exadata X10，本文是基于Exadata X5。当然，型号并不重要，重要的是分析过程。

本文基于2018年的一份白皮书：Using AWR Report on Exadata - Exadata Performance Diagnostics with AWR，文档可以从这里下载。

在Exadata System Overview中，是这么描述的：
Exadata 存储服务器配置和性能统计信息收集在自动工作负载存储库 (AWR) 中，数据可在 AWR 报告中获取。AWR 报告的 Oracle Exadata 部分以 HTML 或活动报告格式提供。

以下部分是 AWR 报告中的三个主要部分：

Exadata Server Configuration：硬件型号信息、软件版本和存储配置
Exadata Server Health Report：脱机磁盘和打开的警报
Exadata Performance Statistics：操作系统统计信息、存储服务器软件统计信息、智能扫描统计信息和按数据库统计信息

AWR 报告提供存储级别性能统计信息，不限于特定实例或数据库。这对于分析一个数据库可能影响另一个数据库性能的情况很有用。

配置差异使用特定颜色突出显示，以便于分析。例如，突出显示与其他单元具有不同软件版本的单元，或与其他单元具有不同内存配置的单元。

自动分析和呈现异常值，以便于性能分析。异常值被适当着色并链接到详细统计信息。

简介

Oracle Exadata 旨在为 Oracle 数据库提供显著更好的性能、成本效益和可用性。Exadata 采用现代云架构，具有横向扩展高性能数据库服务器、具有最先进 PCI 闪存的横向扩展智能存储服务器以及超快 InfiniBand 内部结构。Exadata 中独特的软件算法在存储、计算和 InfiniBand 网络中实现数据库智能，以比其他平台更低的成本提供更高的性能和容量。

Exadata 运行所有类型的数据库工作负载，包括在线事务处理 (OLTP)、数据仓库 (DW)、内存分析和混合工作负载整合。Exadata 可以作为私有数据库云的基础在本地部署，也可以使用订阅模式获取并部署在 Oracle 公共云或客户云中，所有基础设施均由 Oracle 管理。

随着世界各地的客户将 Exadata 作为企业数据库部署的首选平台，并将越来越多的数据库整合到 Exadata 系统上，从 Exadata 系统的角度监控这些数据库的性能变得比以往任何时候都更加重要。本文概述了如何将 Oracle 数据库自动工作负载存储库 (AWR) 功能与 Exadata 结合使用，以从 Exadata 的角度监控和分析数据库性能特征。

本文的内容适用于所有 Exadata 部署 - 无论是本地部署、公共云还是客户云。具体来说，对于 Exadata 云，由于客户对其数据库拥有完全的管理控制权，因此特定于 Exadata 的 AWR 功能的应用方式与这些数据库部署在本地时相同。

AWR 概述

Oracle Database 10g 中引入的自动工作负载存储库 (AWR) 功能是 Oracle 数据库使用最广泛的性能诊断工具。AWR 功能收集、处理和维护数据库性能统计数据，用于问题检测和自我调整。此数据收集过程会定期重复，结果会捕获在 AWR 快照中。根据 AWR 快照捕获的值计算出的增量值表示每个统计数据在一段时间内的变化，可以通过 AWR 报告查看以进行进一步分析。默认情况下，AWR 快照以每小时为间隔拍摄一次，快照会保留八天。AWR 报告也可以按需生成特定时间间隔的 AWR 报告。有关 AWR 的更多详细信息，请参阅 Oracle 数据库性能调整指南中的“收集数据库统计信息”。

性能和范围

在分析性能问题时，了解性能问题的范围并确保使用的数据和工具与问题范围相匹配非常重要。

例如，如果问题局限于一小部分用户或 SQL 语句，则 SQL 监控报告或 SQL 详细信息报告（使用 AWR 需要 Oracle Diagnostics Pack。SQL Monitor 报告和 SQL Details 报告需要 Oracle Diagnostics 和 Tuning Pack。）将包含与问题范围相关的数据。SQL 监控报告提供有关 SQL 语句或 DB 操作的单次执行的详细统计信息，而 SQL 详细信息则提供有关指定时间范围内 SQL 语句的多次执行的详细统计信息。

如果性能问题是实例范围或数据库范围的，则 AWR 报告将包含实例或整个数据库的数据和统计信息。活动会话历史记录或 ASH 可对活动会话进行采样，可用于解决实例范围和数据库范围的问题以及局部问题，因为它可跨多个维度收集数据，可用于过滤数据。

AWR 中的 Exadata 支持

Oracle Database 12.1.0.2.0 和 Exadata System Software
12.1.2.1.0 添加了 AWR 中的 Exadata 支持。通过在 AWR 报告中包含 Exadata 统计信息，客户现在可以通过统一报告查看存储层，而无需从存储服务器收集更多数据。对于拥有公共云和客户云环境的 Exadata 客户来说，这一点尤其重要，因为客户无法访问这些环境中的存储服务器。

Exadata 统计信息仅以 AWR 实例报告和 AWR 全局报告的 HTML 和 Active-HTML 格式提供；统计信息不以报告的文本格式提供。随着新版本的 Exadata 软件中包含新功能，报告中的 Exadata 部分也在不断增强。此外，Exadata 统计信息也可在 Enterprise Manager 中的 AWR 报告中使用。本白皮书中的参考资料部分提供了一系列文档，描述了如何使用 Enterprise Manager 管理 Exadata。

还要注意的是，在 AWR 报告中添加 Exadata 存储级别统计数据后，性能调优方法不会改变。用户应首先查看数据库时间，并找到数据库时间的最大消耗者，以解决性能问题。只有确定可能存在 IO 问题时，才应开始查看 Exadata 部分。Exadata 部分并非旨在替代现有工具和方法，而是旨在补充现有工具和方法。

挑战和 AWR Exadata 解决方案

Oracle DBA 面临的一个相当普遍的挑战是更好地分析和理解与底层基础架构（如服务器、网络和存储）直接相关的数据库性能特征。最佳数据库性能取决于此基础架构的最佳配置；但是，如果此基础架构配置错误或某些组件出现故障，准确诊断由此产生的数据库性能问题并将其与特定组件关联起来并非易事。

Exadata 等工程化系统的价值主张是 Oracle DBA 现在能够将 Exadata 存储服务器上收集和维护的统计数据直接自动集成到 AWR 中。正如本文后面将看到的那样，与将这些数据库部署在通用基础架构上所花费的时间和资源相比，此诊断过程非常高效。随着核心 Exadata 平台通过额外的软件和硬件功能得到增强，特定于 Exadata 的 AWR 内容也不断得到增强，Oracle DBA 也从中受益。

以下各节概述了可以利用 Exadata 特定的 AWR 功能的具体场景。

嘈杂邻居

Exadata 存储在分析性能问题时增加了新的范围。存储子系统可能由多个数据库共享，因此，来自存储层的统计数据适用于整个系统 - 即它不限于单个数据库或单个数据库实例。

在整合了多个数据库的 Exadata 系统中，重要的是要识别可能消耗系统上大量 IO 带宽的数据库，从而影响系统上的其他数据库。这在云部署中通常称为嘈杂邻居问题。但请注意，强烈建议利用 Exadata 的内置 IO 资源管理 (IORM) 功能，以便可以根据配置的资源计划对 Exadata 存储服务器中的 IO 请求进行优先级排序和调度。有关 IORM 的更多详细信息，请参阅 Exadata 系统软件用户指南中的“了解 IO 资源管理”。

为了解决这个嘈杂邻居问题，AWR 报告包含一个按 IO 请求和吞吐量分类的顶级数据库部分。在 AWR 快照时间，数据库的一个子集被捕获到 AWR 中 - 捕获哪些数据库是基于内部指标来确定每个存储服务器中的前 N 个。
如图 1 所示，在报告时，数据被汇总，以便按 IO 请求和 IO 吞吐量报告捕获的顶级数据库。此外，数据按闪存设备上的 IO 和硬盘上的 IO 细分。
在这里插入图片描述
图 1. 按 IO 请求排名的顶级数据库示例。
请注意，报告显示的是 %Captured 而不是 %Total，因为并非所有数据库的所有统计数据都由 AWR 捕获。此数据可针对整个系统（如上所示）和每个单元进行汇总。

单元或磁盘上的工作负载不均衡

Exadata 是一个并行系统，工作负载预计会均匀分布在所有存储
服务器和磁盘上。如果存储服务器或磁盘执行的工作量超过其同类服务器，则有可能导致性能问题。与并行系统通常的情况一样，系统的速度仅与其最慢的组件一样快。

Exadata 报告使用多个指标执行简单的异常值分析，以将设备与其同类设备进行比较。设备按设备类型和大小分组和比较，因为不同类型的设备不具有相同的性能特征。例如，闪存设备的性能预计与硬盘非常不同。同样，1.6TB 闪存设备可能无法维持与 6.4TB 闪存设备相同的 IO 量。

用于异常值分析的统计数据包括 OS 统计数据，类似于 iostat，其中包括 IOP、吞吐量、利用率百分比、服务时间和排队时间。它还包括单元服务器统计信息，这些统计信息按 IO 类型（读取或写入）和 IO 大小（小或大）细分 IOP、吞吐量和延迟。

除了异常值分析之外，Exadata AWR 报告还确定系统是否已达到最大容量。报告中使用的最大值是从单元查询的，与 Exadata 数据表中发布的内容一致。由于客户工作负载会有所不同，因此报告的这些最大数字旨在用作指导原则，而不是硬性规定。
在这里插入图片描述

图 2a。简单异常值分析示例。
此示例中没有异常值，但报告已确定硬盘可能已达到最大 IOPs 容量，如 (*) 和深红色背景所示。系统的最大容量为硬盘 6,408 IOPs，报告当前显示为 9,355.83 IOPs。

图 2b。简单异常值分析示例。
在此示例中，报告已确定硬盘已达到最大容量。它还确定了两个磁盘的 IOPS 高于同类磁盘。

配置差异

与存储服务器或磁盘上的不均匀工作负载类似，存储服务器之间的配置差异可能会导致性能问题。配置问题可能是闪存缓存或闪存日志大小的差异，或使用的单元磁盘或网格磁盘数量的差异。如图 3 和图 3a 所示，AWR 报告包括 Exadata 配置信息，并识别配置不同的存储服务器。
在这里插入图片描述
图 3. 捕获的配置信息示例。
存储服务器模型将包括单元名称。'All’表示存储服务器的配置相同。

在这里插入图片描述
图 3a。从异构系统捕获的配置信息示例。
存储服务器模型包括每个模型的单元名称。“All”表示存储服务器的配置相同，当配置存在差异时，会显示单元名称，如 Exadata Storage Server Version部分所示。

高负载

性能变化可能是由于系统负载增加引起的。这可能是IO 负载增加或存储服务器上 CPU 增加。IO 负载增加可能是由于维护活动（例如备份）或由于用户工作负载增加或执行计划可能发生变化而导致的用户 IO 变化引起的。

在 Exadata 系统上，每个 IO 都会发送附加信息，其中包括数据库执行 IO 的原因。通过 IO 原因，我们可以轻松确定额外的 IO 负载是由维护活动还是由数据库工作负载增加引起的。在这里插入图片描述

报告还可以查看 Exadata 智能功能，包括智能扫描、智能闪存日志和智能闪存缓存。

在这里插入图片描述
图 4. 每个存储单元的 IO 请求的 IO 原因示例。
这表明 IO 请求是由典型的数据库工作负载（重做日志写入和缓冲区缓存读取）引起的。

分析特定于 EXADATA 的 AWR 数据

为了熟悉 AWR 部分，我们将介绍一个可以反映真实客户用例的示例。

场景是，该客户刚刚在 Exadata X5-2 全机架的四个计算节点上部署了一个数据库，并立即开始遇到性能问题。以下部分概述了通过分析报告中特定于 Exadata 的部分可以轻松执行诊断。

查看数据库统计信息

执行的第一个检查是验证系统的 IO 特性。图 5 显示了单个实例的 Top Timed Events，但在这种情况下，所有 4 个实例看起来相当相似。等待事件显示，几乎 75% 的 DB 时间都花在了cell single block physical read上，平均等待时间为 8.32 毫秒。此读取延迟可能意味着数据是从硬盘而不是闪存缓存读取的（从闪存读平均等待时间应为微秒）。
在这里插入图片描述
图 5. AWR 报告中按总等待时间排列的前 10 个前台事件。

进一步查看数据库统计数据后，发现此实例发出的 IO 数量相对较少，为 154.6 IOPs（图 6）。在 4 个实例中，总共只有大约 600 IOPs。

但是，图 6 还显示optimized requests几乎为 0。Exadata 上的优化 IO 包括：

智能闪存缓存上的 IO
来自智能扫描的 IO，包括存储索引保存的 IO 和列式缓存保存的 IO
此数据库似乎没有执行智能扫描工作负载，因此缺乏优化 IO 进一步支持了 IO 未使用闪存缓存的理论。

图 6.AWR 报告中的 IO 配置文件显示此实例的 IO 最少。

图 7 显示了数据库实例发出的 IO 类型，在这个列表中，阻止数据库使用闪存缓存的 IO 类型没有什么特别之处。大多数读取都是Buffer Cache Reads，即数据库为了填充缓冲区缓存而执行的磁盘读取。这些读取通常应该由闪存缓存满足。
在这里插入图片描述
图 7. AWR 报告中按功能汇总的 IOStat 显示了应缓存在闪存缓存中的正常数据库 IO。

一旦验证了 IO 性能问题，下一组分析就可以转向 Exadata配置和统计数据。

Exadata 配置

查看 Exadata 配置部分可发现，它是一台 X5-2 全机架，配有 14 台存储服务器（图 8）。其余配置和运行状况部分未发现任何异常 -
所有存储服务器均按照预期配置以相同方式配置。没有警报，
也没有任何磁盘处于离线状态。为简洁起见，本文未包含这些部分。
在这里插入图片描述
图 8.AWR 报告中的 Exadata 存储服务器模型显示了一个 X5-2 全机架。

IO 分布

对存储服务器上的 IO 进行检查后发现，存储服务器上发生的 IO 并不多（图 9）。但是，硬盘上的 IO 为每单元 564.28/s，比闪存设备上的 IO 为每单元 119.80/s 要多。这种分布在 Exadata 环境中并不常见，因为大多数 IO 通常发生在闪存上。异常值部分报告每个设备类型的 IO，因为不同类型的设备预计具有不同的性能特征。用于识别设备类型的格式为 <F|H>/，其中 F 代表闪存设备，H 代表硬盘。
在这里插入图片描述

图 9.来自 AWR 报告的单元服务器 IOPs

Smart Scans

接下来，我们查看了图 10 所示的智能扫描部分，以确定磁盘读取是否由智能扫描引起。但情况不太可能如此，因为图 9 显示大多数 IO 都是小读取（图 9 显示每秒 133.86 次小读取），而智能扫描通常会被视为大读取（图 9 显示每秒 0.15 次大读取）。快速浏览图 10 中的智能扫描部分，可以确认 IO 不是来自智能扫描，因为每个数据单元只有 1.5MB/s (per Sec列)符合智能扫描的条件。

Smart IO部分还显示了系统上智能 IO 活动的总体情况，并给出了智能扫描执行情况以及存储服务器是否可能受 CPU 限制的提示。但请注意，当查看一小组 SQL 语句的特定智能扫描问题时，SQL Monitor 报告将是一个更好的性能诊断工具。
在这里插入图片描述
图 10.显示智能扫描信息的 AWR 报告中的智能 IO。

Flash Cache

从查看数据库等待事件开始，我们最初怀疑数据是从硬盘读取的，而不是从闪存缓存读取的。如果是这样，预期闪存缓存命中率会很低。请参阅表 1 了解闪存缓存命中率的定义和计算。

在图 11 中，单元 OLTP 命中率（以及单元扫描命中率）非常高，几乎达到 100%。然而，数据库闪存缓存命中率几乎为 0。那么为什么会出现这种差异呢？
在这里插入图片描述
图 11.来自 AWR 报告的闪存缓存节省情况。

统计项	描述
Database Flash Cache Hit%	从闪存缓存中获取的数据库读取请求的百分比
Cell OLTP Hit%	存储服务器上由闪存缓存满足的 OLTP 读取请求的百分比。计算方法如下 $100*(\dfrac{闪存缓存读取请求命中}{闪存缓存读取请求命中+闪存缓存未命中})$
Cell Scan Hit%	存储服务器上由闪存缓存满足的扫描请求百分比。计算方法如下 $100*(\dfrac{闪存缓存扫描读取字节}{尝试闪存缓存扫描字节数})$

表 1. Flash Cache Hit% 定义

Cell Hit%是根据适合**在闪存缓存中缓存的读取次数计算得出的。Exadata 具有智能闪存缓存，可以区分来自数据库的 IO 请求类型，以及将数据缓存在闪存缓存中是否有好处。**Cell Hit%**不包括检索不会从闪存缓存中受益的数据的读取次数。

但是，Database Flash Cache Hit%会考虑来自数据库的所有 IO 请求。

两者之间的差异表明来自数据库的读取次数不适合闪存缓存。

查看来自单元的小读取次数分布（如图 12 所示），发现小读取次数几乎均匀分布在闪存和硬盘之间，其中 53.58% 的小读取次数在硬盘上。
在这里插入图片描述

图 12. AWR 报告中的单块读取指示 OLTP 工作负载

图 13 中的“每秒闪存缓存用户读取次数”显示闪存缓存的读取量非常小。这进一步支持了以下理论：读取未发生在闪存缓存上，因为 IO 请求不符合闪存缓存的条件。

在这里插入图片描述
图 13.来自 AWR 报告的闪存缓存用户读取量。

图 14 显示了各个单元的命中率，并且所有单元的闪存缓存行为都相似。存储单元几乎没有从闪存缓存读取数据，但命中率很高。这意味着磁盘 IO 不是由闪存缓存未命中引起的，而是故意绕过闪存缓存的 IO。
在这里插入图片描述
图 14. AWR 报告中的闪存缓存用户读取效率

图 15 显示了Flash Cache User Writes的回顾，其中还显示了存储单元上的写入量极少。这似乎表明数据库发出的读取和写入都不符合闪存缓存的条件。
在这里插入图片描述
图 15. AWR 报告中的闪存缓存用户写入

在对闪存缓存部分进行最终检查时，还会检查Flash Cache Internal Writes。
这些将是填充写入（population write）请求。闪存缓存未命中通常会导致填充写入，因此对相同数据的后续请求将命中闪存缓存。在这种情况下，闪存缓存中也会有非常少量的填充写入。
在这里插入图片描述

图 16. AWR 报告中的闪存缓存内部写入。
来自闪存缓存部分的所有数据都表明闪存缓存活动非常少，并且
IO 被认为不适合缓存。

IO Reasons

IO 原因部分告诉我们为什么在存储服务器上发出 IO。IO 原因中的 IO 包括读取和写入，以及硬盘和闪存。

在图 17 中，大多数 IO 原因通常缓存在闪存缓存中：

Limit dirty buffer writes – DBWR 发出的写入以限制缓冲区缓存中的脏缓冲区数量
Data file reads to private memory – 这些可能并不总是缓存在闪存缓存中，因为这些是大型读取。但是，这仅占请求的 17%。3
Buffer cache reads – 读入数据库缓冲区缓存。这些是常规用户读取，通常应缓存在闪存缓存中
Redo log writes – 写入重做日志。使用智能闪存日志，这些写入同时对智能闪存日志和重做日志进行。

其余请求仅占约 4%，要么是数据库控制文件读取，要么是内部 IO。内部 IO 是由存储服务器完成的 IO。
在这里插入图片描述
图 17.AWR 报告中按请求列出的 IO 原因。

Top Databases

查看图 18 中的热门数据库，可以验证数据库 DB0003 的大部分 IO 都在磁盘上。
在这里插入图片描述

图 18.AWR 报告中按 IO 请求排名的顶级数据库。

分析摘要

到目前为止，这已经证明了：

数据库的 IO 性能很差。75% 的 DB 时间用于“单元单块物理读取”，平均等待时间超过 8 毫秒。
闪存缓存部分表明闪存缓存上的活动很少，并且 IO 很可能被认为不符合闪存缓存的条件。
IO 原因表明相当典型的 IO 通常应该符合闪存缓存的条件（可能除了读取 PGA）。
顶级数据库确认该数据库正在硬盘上执行其大部分 IO 请求，而不是在闪存上。

审查所有这些数据表明，可能存在配置问题，这是导致 IO 绕过闪存缓存的最可能原因。与客户一起审查配置数据发现，IORM 计划无意中禁用了数据库的闪存缓存。一旦修复了 IORM 计划，性能问题就会自动解决。

Exadata 性能数据

除了 AWR 报告外，Exadata 上还有大量性能数据，包括单元指标和 ExaWatcher。表 2 总结了可用数据以及相关特征：

在这里插入图片描述

表 2. Exadata 上可用的性能数据。

有关单元指标的更多信息，请参阅 Exadata 系统软件用户指南《监控和调整 Oracle Exadata 系统软件》。

结论

AWR 是 Oracle 数据库上使用最广泛的性能诊断工具，现在包含 Exadata 统计数据。与将数据库部署在通用基础架构上相比，将 Exadata 统计数据集成到 AWR 报告中可以更好地、更轻松地分析数据库性能问题。

参考

Exadata Health and Resource Usage Monitoring
Exadata Health and Resource Utilization Monitoring - Exadata Database Machine KPIs
Exadata Health and Resource Utilization Monitoring - Adaptive Thresholds
Exadata Health and Resource Utilization Monitoring - System Baselining for Faster Problem Resolution
Oracle Enterprise Manager for Exadata Cloud - Implementation, Management, and Monitoring Best Practices
Enterprise Manager Oracle Exadata Database Machine Getting Started Guide

参考

How to determine if you are getting all the benefits of Exadata via AWR
Youtube: Speed up transparent performance with Exadata: What, when, how, and why I Oracle Database World
Performance Diagnostics With AWR Reports - Trivadis