本文内容来自Oracle 2024年3月发布的白皮书：Exadata Performance and AWR: Exadata Performance Diagnostics with AWR
简介
本技术简介概述了如何将 Oracle AWR 功能与 Exadata 结合使用，从 Exadata 的角度（standpoint）监控和分析数据库性能特征。
AWR 概述
Oracle Database 10g 中引入的自动负载信息库 (AWR) 是 Oracle Database 使用最广泛的性能诊断工具。AWR 收集、处理和维护数据库性能统计数据，用于问题检测和自我调优。此数据收集过程定期执行，结果捕获到 AWR 快照中。根据 AWR 快照捕获的数据计算出的增量值表示间隔内每个统计数据的变化，可以通过 AWR 报告查看以进行进一步分析。默认情况下，AWR 快照以每小时拍摄一次，快照保留八天。建议增加保留期，以便进行每月（31 天）或每季度（90 天）的比较，具体取决于您的报告和保留要求。AWR 报告也可以按需生成特定时间间隔的 AWR 报告。
关于AWR的详细介绍，可以参见Oracle Database Performance Tuning Guide中的About Gathering Database Statistics一节。
性能问题的范围
在分析性能问题时，了解性能问题的范围并确保用于分析的数据和工具与问题范围相匹配非常重要。
例如，如果问题局限于一小部分用户或 SQL 语句，则 SQL 监控报告将包含与问题范围相关的数据。SQL 监控报告提供有关 SQL 语句或数据库 (DB) 操作的单次执行的详细统计信息。
如果性能问题是实例范围或数据库范围的，则 AWR 报告将包含实例或整个数据库的数据和统计信息。活动会话历史记录 (ASH) 可对活动会话进行采样，可用于实例范围、数据库范围和本地问题。ASH 收集多个维度的数据，可用于过滤数据。
维护基线
统计基线是通常在系统运行良好的时间段内 收集的统计数据的集合。通过将基线中捕获的统计数据与性能不佳期间捕获的统计数据进行比较，可以使用基线来诊断性能问题。这样可以识别可能大幅增加的统计数据，这可能是问题的原因。
建议在正常处理期间以及关键时间范围（例如月末或年末处理）收集基线。基线应包括 AWR 数据（基线应该包括实际的 AWR 数据，而不仅仅是 AWR 报告）、一些关键 SQL 语句的 SQL 监视器报告以及来自存储服务器的其他统计数据（ExaWatcher 和Cell指标历史记录）。
注：在Oracle Exadata System Software文档中，有关 AWR、ExaWatcher 和Cell指标历史记录的信息，可参见文档：Oracle Exadata System Software -- Monitoring Exadata
AWR 中的 Exadata 支持
Oracle Database 12.1.0.2.0 和 Exadata System Software 12.1.2.1.0 引入了 AWR 中的 Exadata 支持。在 AWR 报告中包含 Exadata 统计信息可通过统一报告更深入地了解存储层，而无需从存储服务器收集额外数据。这对于无法访问存储服务器的 ExaDB-D 和 ExaDB-C@C 客户尤其有用。
Exadata 统计信息仅在 AWR 实例报告的 HTML 和 Active-HTML 格式以及 CDB$ROOT 的 AWR 全局报告中可用。Exadata 统计信息不在文本格式的报告中提供；也不在 PDB 级 AWR 报告中提供。报告中的 Exadata 部分也在不断增强，因为新版本的 Exadata 软件中包含了新功能。Exadata 统计信息也可在 Enterprise Manager 的 AWR 报告中使用。本技术简介中的参考资料部分提供了一系列文档，介绍如何使用 Enterprise Manager 管理 Exadata。
还要注意的是，在 AWR 报告中添加 Exadata 存储级别统计信息后，性能调优方法并未改变。用户应首先查看 DB time，然后通过分析 DB time的主要消耗者来解决性能问题。只有确定可能存在 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 报告包含一个 Top Databases 部分，其中显示了 IO 请求和 IO 吞吐量。此部分有助于比较每个数据库的 IO 资源消耗。根据内部指标在 AWR 快照中捕获数据库的子集，以确定每个存储服务器中的前 N 个数据库。Exadata 上的 AWR 报告按 IO 请求和 IO 吞吐量显示顶级数据库。如图 1 所示，数据按闪存设备上的 IO 和硬盘上的 IO 细分。在图 2 中，请求进一步细分为小型和大型 IO，以及平均 IO 延迟和 IO 的平均 IORM 排队时间。
图 1. 按 IO 请求数排名的顶级数据库
图 2. 请求量排名靠前的数据库 - 详细信息
单元或磁盘上的工作负载不均匀
Exadata 旨在将工作负载均匀地分布在所有存储服务器和磁盘上。如果存储服务器或磁盘执行的工作量超过同类设备，则可能会导致性能问题。
Exadata AWR 报告执行异常值分析，使用多个指标将设备与同类设备进行比较。设备按设备类型和大小分组和比较，因为不同类型的设备不具有相同的性能特征。例如，闪存设备的性能预计与硬盘有很大不同。同样，1.6 TB 闪存设备可能无法维持与 6.4 TB 闪存设备相同的 IO 量。
用于异常值分析的统计数据包括操作系统统计数据，如 iostat，其中包括 IOPs、吞吐量、利用率百分比、服务时间和队列时间（作为操作系统统计信息的一部分报告的队列时间是设备队列时间，而不是 IORM 队列时间）。异常值分析还包括单元服务器统计数据，按 IO 类型（读取或写入）和 IO 大小（小或大）细分 IOPs、吞吐量和延迟。
Exadata AWR 报告可确定系统是否已达到其最大容量。报告中使用的最大值是从单元查询的，与 Exadata 数据表中发布的内容一致。由于客户工作负载会有所不同，因此报告的最大数字旨在用作指导原则，而不是硬性规定。
自动硬盘清理和修复 (scrub) 是 Exadata 的一项功能，可主动检查磁盘上的扇区是否存在物理错误，从而可以检测到内置硬盘功能可能无法检测到的问题。清理是 Exadata 上的一个自动化过程，当磁盘处于空闲状态（少于 25% 的繁忙度）时启动，以免影响数据库性能，默认情况下每两周执行一次（详见博客）。
当 Exadata 清理运行时，读取次数通常会超过最大 IOP。清理发出连续的 16 KB 读取。Exadata 软件旨在优先考虑客户端 IO 而不是清理 IO。当发出客户端 IO 时，清理 IO 将退出以允许客户端 IO 继续进行，因此清理预计不会影响客户端 IO。
图 3 显示了存储单元异常值分析的示例。此示例中没有异常值，但报告已确定硬盘可能处于最大 IOPs 容量，如 * 和深红色背景所示。系统的最大硬盘 IOPs 为 6,408(这应该是个经验值，在Exadata datasheet中找到最相近的值是MAXIMUM SQL DISK IOPS)，报告当前显示为 9,355.83 IOPs。
图 3.Exadata OS IO 统计数据 - 异常单元
图 4 显示了磁盘异常值分析的示例。在此示例中，报告已确定硬盘处于最大容量。它还确定了两个磁盘的 IOPs 性能高于同类磁盘。
图 4.Exadata OS IO 统计数据 - 异常磁盘
配置差异
存储服务器之间的配置差异可能会导致性能问题。配置问题可能是 Oracle Smart Flash Cache（闪存缓存）或 Oracle Smart Flash Log（闪存日志）大小的差异，或使用的单元磁盘或网格磁盘数量的差异。
AWR 报告包括 Exadata 配置信息并识别配置不同的存储服务器。图 5 显示了具有相同存储服务器配置的系统示例。在 Exadata 配置部分中，"All"表示所有存储服务器的配置相同。如果单元配置之间存在差异，则将显示单元名称，如图 6 中的 Exadata Storage Server Version 部分所示。
图 5. 具有相同存储服务器配置的系统。
图 6. 具有不同存储服务器配置的系统
高负荷
性能变化可能是由于系统负载增加引起的。这可能是存储服务器上的 IO 或 CPU 负载增加。IO 负载增加可能是由于维护活动（例如备份）或用户 IO 变化（由于用户工作负载增加或执行计划可能发生的变化）引起的。
在 Exadata 系统上，每次 IO 都会发送附加信息，包括数据库执行 IO 的原因。通过 IO 原因，我们可以轻松确定额外的 IO 负载是由维护活动还是由增加的数据库工作负载引起的。
报告还可以查看 Exadata 智能功能，包括智能扫描、智能闪存日志和智能闪存缓存。
图 7 显示了一个示例，其中排名靠前的 IO 请求是由典型的数据库工作负载（重做日志写入和缓冲区缓存读取）引起的。
图 7. 按请求列出的主要 IO 原因
DB Time 和 等待事件
与存储相关的性能问题通常表现为 IO 相关等待事件上 DB 时间的增加。数据库有各种等待事件，它们指示正在执行的 IO 类型。当存在与存储相关的问题时，这些等待事件的平均等待时间以及 DB 在这些等待事件中花费的时间百分比的增加在 AWR 报告中显而易见。
结合上一节中讨论的 AWR Exadata 部分，数据库等待事件可以与 Exadata 部分中的特定统计数据相关联，以确定存储服务器上 IO 的处理方式。
在许多情况下，IO 延迟缓慢是由于从硬盘服务的 IO 数量增加，而不是利用闪存缓存或 XRMEM 缓存。关键是要确定为什么 IO 没有从 Exadata 缓存中获得服务。
Exadata 性能摘要和范围
在查看 AWR 报告中的 Exadata 部分时，请注意指示所显示统计信息范围的描述。性能摘要包括数据库统计信息和存储统计信息。这可以更轻松地将两者联系起来。但是，数据库统计信息显示生成 AWR 报告的单个数据库的数据；而存储统计信息显示在存储服务器上收集的数据，其中包括在这些服务器上运行的所有数据库。
单块读
如图 8 所示，与单块读取相关的等待事件是存储 IO 性能的良好指标。数据库上的单块读取转换为存储服务器上的小读取。等待事件还指示读取发生的介质。
单块读取通常是 OLTP 系统中的主要 IO 等待事件。单元单块物理读取的长延迟可能代表潜在的存储相关问题。
图8 统计范围
表 1 列出了不同单元的单块读取等待事件。每个单块读取的平均延迟会有很大差异，具体取决于读取的来源介质。
图 9 显示了单块读取的等待次数主要来自 RDMA 的系统。但是，由于 RDMA 的延迟要低得多，因此等待次数越多通常会消耗更少的总体 DB 时间。
| 等待事件 | 描述 |
|---|---|
| cell single block physical read: RDMA | 使用 RDMA 从 XRMEM Cache 读取单块的等待事件 |
| cell single block physical read: xrmem cache | 等待从 XRMEM Cache 读取单个块的事件 |
| cell single block physical read: flash cache | 等待从闪存缓存读取单个块的事件 |
| cell single block physical read | 等待从磁盘或容量优化闪存（即闪存作为磁盘而非缓存）读取单个块的事件 |
表 1. 单元单块读取等待事件
图 9. 单元单块读取等待事件
表 2 说明了磁盘读取的成本。与单元单块物理读取相关的等待事件总数为 12,890,878（即图9中Total Waits列的合计），等待事件所花费的总时间为 9,544.72 秒（即表2中总DB time列的合计）。即使只有 2% （对应表2中第一行的1.9）的单元单块物理读取等待计数发生在磁盘上，它也占了等待时间的 82% （对应表2中第一行的82.7）以上。因此，如果必须从硬盘提供大量读取服务，通常会导致明显的性能问题。
| 等待事件 | 总DB time (Total Waits 乘以 Avg Wait) | % of Wait Count | % of Wait Time |
|---|---|---|---|
| cell single block physical read | 7,892.22s (244,720 * 32.25ms) | 1.9 | 82.7 |
| cell single block physical read: RDMA | 310.30s (10,058,614 * 30.85us) | 78.0 | 3.2 |
| cell single block physical read: flash cache | 1,205.83s (1,856,747 * 649.43us) | 14.4 | 12.6 |
| cell single block physical read: xrmem cache | 136.37s (730,797 * 168.61us) | 5.7 | 1.4 |
表 2. 磁盘读取成本
Exadata 性能摘要包括一个部分，用于指示如何处理小的读取。图 10 表明 30.73% 的数据库 IO 由闪存缓存提供，另外 71.97% 来自 XRMEM 缓存（其中 53.59% 通过 RDMA 读取完成）。这是一个性能良好的数据库，其中大多数读取都由 Exadata 缓存满足。
注：总缓存命中率有时会超过 100%，因为某些类型的读取被计为缓存命中（分子），但不计为物理读取 IO 请求（分母）。控制文件读取就是一个例子。
当数据库使用 XRMEM 缓存执行 RDMA 读取时，读取请求不会转到单元。相反，数据库直接从存储服务器上的 XRMEM 缓存读取，从而实现极快的读取延迟。在这种情况下，存储服务器不考虑数据库执行的 RDMA 读取，Exadata 部分不考虑这些 RDMA 读取。相反，RDMA 读取取自数据库统计信息。
Exadata XRMEM 缓存部分反映了未通过 RDMA 的数据库读取请求。在这种情况下，读取请求被发送到存储服务器，存储服务器处理读取请求，然后可能导致 XRMEM 缓存命中或未命中。
当大多数读取请求由 XRMEM 缓存提供服务时，可能会获得较低的闪存缓存命中率，如图 10 所示。这可能不一定令人担忧，因为这可能只是由于针对闪存缓存的读取请求数量较少。此模式通常表示正在访问需要读入缓存的新数据。
图 10. 性能摘要 - 缓存节省
由于性能问题可能源于过多的磁盘 IO，而这些 IO 无法从 Exadata 缓存中获益，因此 Exadata Performance Summary -- Disk Activity部分（如图 11 所示）也显示了磁盘 IO 的潜在原因。
图 11. 性能摘要 -- 磁盘活动
如图 12 所示，每个单元每秒针对闪存缓存的 OLTP 读取请求仅为约 200 个。这包括在 Exadata 系统上运行的所有数据库。考虑到闪存缓存的读取请求率相当低，再加上 XRMEM 缓存的高命中率，这表明低闪存缓存命中率可能对这个特定数据库的性能影响很小。但是，如果我们看到数据库的缓存命中率低，再加上闪存缓存的高未命中率，则可能表明读取是从磁盘获得的，这值得进一步调查。
图 12. 闪存缓存用户每秒读取次数
除了闪存缓存未命中之外，从磁盘读取单个块也可能是由闪存缓存跳过（flash cache skip）引起的。当读取绕过闪存缓存时，会发生闪存缓存跳过，因为它们被标记为不适合在闪存缓存中缓存。图 13 显示，由于存储子句（Storage Clause），读取正在绕过闪存缓存，这表明段指定了存储子句，其中包含 cell_flash_cache NONE。
图 13.闪存缓存用户读取 - 跳过
除了查看闪存缓存部分，还应检查：
- 跨单元/磁盘的不平衡
- Top Database 部分
- Small Read Histogram 部分 - 如果单元上的直方图没有显示问题，但数据库上的直方图显示较长的延迟，则表明不是 IO 导致较大的延迟，而可能是网络或 IORM 排队上的问题。
Smart Scan
智能扫描的等待事件可能因系统而异，甚至因查询而异。除了 IO 时间外，等待事件还包括存储上卸载的所有处理。处理成本取决于卸载的操作类型，因为某些操作比其他操作更耗 CPU。
在大多数情况下，用户将看到cell smart table scan等待事件。如果发生 passthru，等待事件将指示 passthru 的原因。
| Wait Event | Description |
|---|---|
| cell smart table scan | 会话等待智能扫描完成时的等待事件 |
| cell smart table scan: db timezone upgrade | 由于正在进行数据库时区升级，单元无法卸载时的等待事件 |
| cell smart table scan: disabled by user | 由于用户设置，单元无法卸载时的等待事件 |
| cell smart table scan: passthru | 单元无法卸载智能扫描时的等待事件 |
表 3. 智能扫描等待事件
单元智能表扫描延迟增加的原因有很多。一些常见原因是passthru、磁盘 IO 增加、存储索引保存不足或列缓存不足。在某些情况下，数据库可能会回退到block IO 模式（相对于Smart Scan模式）下执行。
对于智能扫描，查看受其影响的性能较差的特定查询通常很有用。SQL Monitor 是另一个非常有用的工具，可用于诊断智能扫描问题。还有数据库统计数据可用于了解智能扫描性能并将其与存储服务器统计数据关联起来。
"Performance Summary"部分包括Smart Scan Summary，其中可以关联数据库和存储端统计数据。在图 14 中，我们看到数据库发出大约 5.2 GB/s 的符合智能扫描条件的数据（cell physical IO bytes eligible for smart IOs），其中大部分由于正在进行的在线加密而回退到块 IO 模式（cell num bytes in block IO during predicate offload）。
有许多数据库端统计数据表明智能扫描可能无法卸载的原因。这些统计数据在 Exadata 存储软件用户指南 - 监控 Exadata 中进行了描述。
图 14. 性能摘要：智能扫描摘要
图 15 所示的 Exadata Smart IO 部分指示存储服务器正在处理的符合智能扫描条件的 IO 数量。它还指示从闪存读取的存储索引节省字节数、从磁盘读取的字节数以及列式缓存使用情况。它还指示是否正在发生直通或反向卸载。
图 15.Exadata 智能 IO
除了 Exadata Smart IO 部分，Flash Cache User Reads 部分还显示了为扫描和列式缓存执行的 IO 数量，如前面的图 12 所示。
除了查看 Smart IO 和各种 Flash Cache 和列式缓存部分外，还应检查：
- 跨单元/磁盘的不平衡：智能扫描应均匀地命中所有单元/磁盘。如果单个单元/磁盘执行缓慢，则会影响扫描延迟。扫描通常是存储服务器上的大型读取。
- Top Databases：大型 IO 的 IORM 排队时间也会导致智能扫描延迟。
Temp Spill
当数据库执行临时 IO 时，理想情况下，临时 IO 将被吸收到闪存缓存中。其他大型写入操作也有可能被吸收到闪存缓存中，但可能会因各种原因而被拒绝（称为Temp Spill）。当数据库临时 IO 相关等待事件的延迟增加时，通常与临时操作未被吸收到闪存缓存中有关。
| 等待事件 | 描述 |
|---|---|
| direct path write temp | 会话写入临时文件时的等待事件 |
| direct path read temp | 会话读取临时文件时的等待事件 |
表 4. Temp相关等待事件
如图 16 所示，Flash Cache User Writes - Large Writes 部分显示了存储服务器正在处理的大型写入的数量和大型写入的类型。
图 16.闪存缓存用户写入 - 大的写入
Flash Cache User Writes - Large Write Rejections 表明我们可能无法将大量写入（或Temp Spill）吸收到闪存缓存中的原因。在图 17 中，由于全局限制，大多数大的写入被拒绝。这意味着大的写入已超出可用于大写入的最大闪存缓存空间量。
图 17.闪存缓存用户写入 - 大量写入拒绝
图 18 中的Flash Cache Space Usage 显示，大约 20% 的闪存缓存用于大型写入，这是闪存缓存中可用于大型写入的最大量。通常，可以通过调整查询以减少对临时空间的需求来解决此问题。在某些情况下，临时需求的增加归因于应用程序升级（这会导致一组新的查询）或数据库升级（这会导致优化器执行计划更改）。如果工作负载需要更多闪存缓存空间用于临时 IO，您还可以查看 main_workload_type 数据库参数的使用情况，如 Exadata 数据库机系统软件用户指南 - 针对分析工作负载优化 Exadata 智能闪存缓存中所述。
图 18.闪存缓存空间使用情况
除了查看闪存缓存部分，还应检查：
- IO 延迟：临时溢出（Temp Spill）通常是存储服务器上的大量写入。
- Top Databases：大型 IO 的 IORM 排队时间也会影响智能扫描延迟。当硬盘繁忙时，硬盘上的 IORM 排队时间会增加。
示例场景：分析特定于 Exadata 的 AWR 数据
为了帮助您熟悉 Exadata 部分，我们将介绍一个反映真实客户用例的示例。在此示例中，客户已迁移到新的 Exadata 系统，并且遇到了性能下降问题。
查看数据库统计信息
一个好的起点是通过查看 AWR 报告中的 Top Timed Events 来检查性能问题是否可能与存储有关。图 19 和图 20 显示了单个实例的 Top Timed Events，但在这种情况下，所有实例看起来都很相似。等待事件显示，几乎 62% 的 DB 时间花在了单元智能表扫描上，平均等待时间刚好超过 1.6 秒。
在图 19 中，此示例中的数据库版本没有分隔符来指示等待事件的读取发生位置，如表 3 中先前所述。但是，单元单块物理读取的延迟为 71.06 微秒，这意味着大多数单块读取都是通过 RDMA 执行的。
图 19. 按总等待时间排名的前 10 个前台事件
从图 20 所示的 Exadata Performance Summary 部分中，我们可以看到许多 IO 由 RDMA 读取服务。但是，RDMA 读取通常用于 OLTP 或块 IO 格式 ，不会给智能扫描带来好处。
图 20. Exadata 性能摘要
如果我们进一步查看图 21 中的磁盘 IO 来源，我们可以看到 Flash Cache 读取跳过和 Flash Cache 写入跳过的数量很高。跳过表示 IO 不符合闪存缓存的条件。我们还看到清理正在运行（Scrub IO），但如前所述，系统设计为优先处理客户端 IO 而不是清理 IO。
图 21. 磁盘活动
Exadata 配置
查看图 22 中的 Exadata 配置部分，我们发现该系统是具有 12 个存储服务器的 X9M-2。
图 22. Exadata 配置：Exadata 存储服务器模型
图 23 显示，潜在问题的第一个迹象是 celadm11 和 celadm12 的配置与其他存储单元略有不同 -- 没有闪存日志，并且闪存缓存稍大一些。
图 23. Exadata 配置：Exadata 存储信息
IO 分配
异常部分报告每个设备类型的 IO，因为不同类型的设备具有不同的性能特征。用于识别设备类型的格式是 <F|H>/<size>，其中 F 代表闪存设备，H 代表硬盘。对于 Extreme Flash 存储服务器，容量优化和性能优化的闪存设备都将报告为 F/<size>，其中 <size> 表示闪存设备的类型（例如，X10M EF 服务器将容量优化的闪存设备报告为 F/14.0T，性能优化的闪存设备报告为 F/5.8T）。
查看图 24 中的存储服务器上的 IO 表明 celadm11 和 celadm12 上存在离群值。虽然我们看到来自其他单元的大量 IO（由于清理），但我们看到 celadm11 和 celadm12 上的模式完全不同。这两个单元显示 IOPs 约为 479，利用率几乎为 100%。
图 24. OS 统计数据 - 异常的单元
进一步查看图 25 中的单元服务器统计数据，我们还会看到 celadm11 和 celadm12 上的不同 IO 类型 - IO 主要是小写入，也有一些大写入。其他存储单元上的小读取与清理（Scrub）相关。
虽然扫描由存储服务器上的大读取组成，但不同的 IO 配置文件，特别是 celadm11 和 celadm12 上的大量写入和高磁盘利用率令人担忧。
图 25. 单元服务器统计信息 - 异常单元
Smart Scan
Smart IO 部分还显示了系统上智能 IO 活动的总体情况，并提供了智能扫描的执行情况（当查看仅影响一小部分 SQL 语句的特定智能扫描问题时，SQL Monitor 是一个很好的诊断工具。）。在图 26 中，我们看到 celadm11 和 celadm12 的行为与其他存储单元不同。虽然磁盘 IO 不是很高，但它们明显高于其他单元，这些单元的智能扫描几乎完全来自闪存缓存。
图 26. 显示智能扫描信息的 AWR 报告中的智能 IO
Smart Flash Log
从 Exadata 配置部分，我们看到 celadm11 和 celadm12 上的闪存缓存和闪存日志的配置与其他存储单元上的配置不同。尽管重做日志写入不是问题，但我们仍然看到这两个单元上的闪存日志行为存在差异。在图 27 中，我们看到这两个单元上的跳过，原因是由于未配置闪存日志。这与在 Exadata Configuration - Storage Information 部分中观察到的信息一致。
图 27.Flash Log Skip Details 显示 celadm11 和 celadm12 没有闪存日志
Smart Flash Cache
从 Exadata Configuration - Storage Information部分，我们知道正在调查的两个单元上的闪存缓存略大。图 28 中显示的闪存缓存配置部分为我们提供了更多见解，在本例中突出显示了问题最可能的原因。
Flash Cache Configuration显示两个感兴趣的单元处于normal - flushing状态。处于正常 - 刷新状态的存储单元表示闪存缓存中的数据当前正在刷新到硬盘，客户端 IO 将无法使用闪存缓存。相反，这些客户端 IO 将被重定向到硬盘。
图 28.闪存缓存配置显示了单元之间的差异
尽管这已经看起来是问题的原因，但为了尽职调查，我们检查了其他部分，以确保其他单元没有其他问题。
图 29 中的闪存缓存用户每秒读取次数显示，相同的两个单元的未命中率高于其他单元，请求率低于其他单元。
图 29. 闪存缓存用户每秒读取次数
此外，图 30 中的闪存缓存用户读取效率表明，在相同的两个单元中，OLTP 和扫描的命中百分比率 (%Hit) 明显较低。
图 30. 闪存缓存用户读取效率
同样，查看图 31 中的闪存缓存用户写入部分，celadm11 和 celadm12 在报告间隔内有超过 1900 万次部分写入（partial writes），每秒有 5000 次部分写入。部分写入并不常见，当写入同时进入闪存缓存和硬盘时就会发生。这两个单元上的部分写入同样是闪存缓存normal - flushing状态的结果。
图 31.闪存缓存用户写入
类似地，如图 32 所示，Flash Cache User Writes - Skips 显示 celadm11 和 celadm13 上的写入绕过了闪存缓存。在此特定 AWR 报告中，我们看到有写入绕过了闪存缓存，但我们看不到发生这种情况的原因。从 Oracle Database 19.19 开始，将提供其他信息来使原因更加明显。在这种情况下，我们可以假设这些写入可能是由于闪存缓存的normal - flushing状态造成的。
图 32.闪存缓存用户写入 - 跳过
如图 33 所示，Flash Cache Internal Reads 部分显示了磁盘写入器活动。Disk Writer 负责将脏数据从闪存缓存同步到硬盘。从 Oracle Database 19.19 开始，AWR 报告还包括Disk Writer写入的类型，这将显示写入是否与刷新相关。在本例中，我们在 celadm11 和 celadm12 上看到更多写入，我们可以假设这是刷新的结果。
图 33.闪存缓存内部读取
最后，如图 34 所示，闪存缓存内部写入部分表明写入不会进入 celadm11 和 celadm12 上的闪存缓存。通常，闪存缓存的填充是由于闪存缓存未命中而发生的。在这种情况下，尽管未命中次数较多，但没有填充写入，这与刷新操作一致。
图 34.闪存缓存内部写入
Flash Cache 部分均指示 celadm11 和 celadm12 上的闪存缓存中有活动（或在某些情况下缺少 IO），两者都显示正常状态 - 刷新。
此时，我们可以放心地说，这两个单元上的闪存缓存的状态是导致观察到的问题的主要原因。但我们将继续使用其余部分来验证我们的假设。
IO Reasons
IO Reasons 部分告诉我们为什么在存储服务器上发出 IO。IO Reasons中的 IO 包括读取和写入，以及硬盘和闪存设备。
在图 35 和图 36 中，我们看到 celadm11 和 celadm12 上的 IO 原因与其他存储单元不同。
其他单元显示：
- 清除 IO -- 这会导致从硬盘读取少量数据，通常不会影响客户端。
- 重做日志写入 -- 写入重做日志。使用智能闪存日志和智能闪存日志回写（Oracle Exadata 系统软件 20.1.0 中引入了Smart Flash Log Write-Back功能），重做日志写入预计会转到闪存日志和闪存缓存。
- 智能扫描 -- 智能扫描活动。
- 有限的脏缓冲区写入、DBWR 的陈旧写入和中等优先级检查点写入 -- 来自数据库写入器的写入。
存储单元 celadm11 和 celadm12 显示 36-37% 的 IO 归因于内部 IO，这比其他单元高得多。另请注意，scrub 没有在 celadm11 和 celadm12（这两个单元我们发现了问题）上运行。
图 35. 按请求划分的 IO 原因
图 36 显示了内部 IO 的潜在原因。此信息汇总到所有单元。链接将直接显示 AWR 报告的相关部分，其中包含各个单元的统计信息。
图 36. 内部 IO 原因。
Top Databases
查看图 37 中的顶级数据库，可以看到所有数据库上的大型 IO 的磁盘 IO 延迟都有所增加。磁盘 IO 延迟的增加还会导致大型 IO 的 IORM 排队增加。这些较大的延迟直接影响数据库中出现的单元智能表扫描等待事件。
图 37. 请求最多的数据库 - 详细信息
在图 38 中更详细地查看存储单元，我们看到高延迟和高 IORM 队列时间仅发生在两个单元 celadm11 和 celadm12 上 - 这两个单元是我们一直在审查的。
图 38. 按每个单元的 IO 请求数排名靠前的数据库 - 详细信息
分析摘要
以下是我们从此示例的分析中了解到的信息的摘要：
- 数据库的 IO 性能不佳，主要在cell smart table scan等待事件中观察到。
- Flash Cache Configuration 指示两个单元处于normal - flushing 状态。这意味着闪存缓存正在将其所有数据刷新到硬盘，并且这些单元上的 IO 可能无法使用闪存缓存。这两个单元上的 IO 模式差异在所有其他Flash Cache部分中都很明显。
- IO Outliers显示相同两个单元上的 IO 异常值。这两个单元上的 IO 模式表明写入活动增加。其他单元显示由于清理而增加的小读取活动。
- Smart IO 再次表明这两个单元的 IO 服务方式存在差异。
- IO reasons 显示这两个单元上的 IO 模式不同，与在其他Flash Cache部分观察到的情况一致。
- Top Databases显示 IO 延迟增加，导致这两个单元上的 IORM 排队时间增加。这些延迟直接影响单元智能表扫描等待事件。
查看数据表明主要问题是对两个单元的闪存缓存发出了刷新。不应在具有活动数据库工作负载的系统上执行刷新，因为该选项会阻止数据缓存在闪存缓存中。在这种情况下，执行了维护活动以尝试缓解两个单元上闪存日志的缺失，但在高峰期无意中执行了该维护活动，从而导致了观察到的性能问题。为了缓解该问题，必须使用 ALTER FLASHCACHE CANCEL FLUSH 取消刷新操作。
Exadata Performance Data
除了 AWR 报告之外，Exadata 上还提供丰富的性能数据，包括单元指标和 ExaWatcher。
表 5 总结了每个性能数据类别的可用数据和相对特征：
性能数据
表 5. Exadata 上可用的性能数据。
结论
自动工作负载存储库是 Oracle 数据库最广泛使用的性能诊断工具。在 Exadata 上运行的 Oracle 数据库中的 AWR 数据包括额外的 Exadata 统计数据。与将数据库部署在通用基础架构上相比，将 Exadata 统计数据集成到 AWR 报告中可以更好、更轻松地分析数据库性能问题。
有关更多信息，请参阅：Oracle Exadata 系统软件用户指南 -- 监控 Exadata
参考
- Oracle Exadata 系统软件用户指南 -- 监控 Exadata
- Exadata 运行状况和资源使用情况监控
- Exadata 运行状况和资源利用率监控 -- Exadata 数据库机 KPI
- Exadata 运行状况和资源利用率监控 -- 自适应阈值
- Exadata 运行状况和资源利用率监控 -- 系统基准测试以更快地解决问题
- Oracle Enterprise Manager for Exadata Cloud -- 实施、管理和监控最佳实践
- Enterprise Manager Oracle Exadata 数据库机入门指南
参考
- Exadata Performance and AWR v2.0 2024
- Using AWR Report on Exadata - 2018