通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure NetApp 文件多个卷上的 Oracle 数据库性能

  • 项目

将高性能的 Exadata 级别数据库迁移到云端，对 Microsoft 客户来说正变得越来越重要。 由于单个计算节点驱动的混合读写工作负载对存储 I/O 有着极高的要求，供应链软件套件通常设定了较高的标准。 Azure 基础结构与 Azure NetApp 文件相结合，可满足此高要求工作负载的需求。 本文举例说明如何为一个客户满足此需求，以及 Azure 如何满足关键 Oracle 工作负载的需求。

企业级 Oracle 性能

在探索性能上限时，请务必识别和减少任何可能错误扭曲结果的约束。 例如，如果目的是证明存储系统的性能能力，那么理想情况下，应该配置客户端，使 CPU 在达到存储性能限制之前不会成为一个缓解因素。 为此，测试从 E104ids_v5 实例类型开始，因为这种虚拟机不仅配备了 100 Gbps 的网络接口，还具有同样大的 (100 Gbps) 流出量限制。

测试分为两个阶段：

  1. 第一阶段专注于使用 Kevin Closson 的目前行业标准 SLOB2 (Silly Little Oracle Benchmark) 工具版本 2.5.4 进行测试。 目标是尽可能多地将 Oracle I/O 从一个虚拟机 (VM) 驱动到多个 Azure NetApp 文件卷，然后使用更多数据库进行横向扩展，以演示线性缩放。
  2. 在测试了扩展限制之后，我们的测试转向了成本更低但几乎同样强大的 E96ds_v5，用于客户测试阶段，该阶段使用真正的供应链应用程序工作负载和现实世界的数据。

SLOB2 纵向扩展性能

以下图表记录了单个 E104ids_v5 Azure 虚拟机运行单个 Oracle 19c 数据库以及八个 Azure NetApp 文件卷和八个存储终结点的性能概况。 卷分布于三个 ASM 磁盘组：数据、日志和存档。 五个卷分配给数据磁盘组，两个卷分配给日志磁盘组，一个卷分配给存档磁盘组。 本文记录的所有结果都是使用生产 Azure 区域和活动的生产 Azure 服务收集的。

要在多个存储终结点上使用多个 Azure NetApp 文件卷在 Azure 虚拟机上部署 Oracle，请使用 Oracle 应用程序卷组。

单主机体系结构

以下图表描述了测试完成所针对的架构；请注意，Oracle 数据库分布在多个 Azure NetApp 文件卷和终结点上。

包含 Azure NetApp 文件容量池的 Oracle 子网示意图。

单主机存储 IO

以下图表显示了 100% 随机选择的工作负载，数据库缓冲区命中率约为 8%。 SLOB2 能够维持亚毫秒级的 DB 文件顺序读取事件延迟，同时驱动大约每秒 850,000 个 I/O 请求。 数据库块大小为 8K，相当于大约 6,800 MiB/秒的存储吞吐量。

显示单主机随机存储 I/O 的图表。

单主机吞吐量

以下图表显示，对于带宽密集型顺序 IO 工作负载，如全表扫描或 RMAN 活动，Azure NetApp 文件可以提供 E104ids_v5 虚拟机本身的全部带宽能力。

显示单主机顺序吞吐量的条形图。

注意

由于计算实例是其带宽的理论最大值，因此添加额外的应用程序并发只会增加客户端延迟。 这会导致 SLOB2 工作负载超过目标完成时间范围，因此线程计数上限为 6。

SLOB2 横向扩展性能

以下图表记录了三个 E104ids_v5 Azure VM 的性能概况，每个虚拟机都运行一个单独的 Oracle 19c 数据库，并且每个虚拟机都有自己的一套 Azure NetApp 文件卷，并且都遵循与扩展性能部分所述相同的 ASM 磁盘组布局。 这些图表显示，使用 Azure NetApp 文件多卷/多终结点，性能可以轻松地一致和可预测地横向扩展。

多主机体系结构

以下图表描述了测试完成所针对的架构；请注意，三个 Oracle 数据库分布在多个 Azure NetApp 文件卷和终结点上。 终结点可以专用于单个主机，如 Oracle VM 1 所示，或在主机之间共享，如 Oracle VM2 和 Oracle VM 3 所示。

Azure NetApp 文件的 Oracle 自动存储管理示意图。

多主机存储 IO

以下图表显示了 100% 随机选择的工作负载，数据库缓冲区命中率约为 8%。 SLOB2 每秒可跨所有三个主机单独驱动大约 850,000 个 I/O 请求。 SLOB2 能够在并行执行的同时，达到总共约每秒 2,500,000 个 I/O 请求，同时每个主机仍然保持亚毫秒级的 DB 文件顺序读取事件延迟。 数据库块大小为 8K，这相当于三个主机之间大约 20,000 MiB/秒。

从 I/O 角度看的集体随机存储折线图。

多主机吞吐量

以下图表显示，对于顺序工作负载，即使向外扩展，Azure NetApp 文件仍然可以提供 E104ids_v5 虚拟机本身的全部带宽能力。 SLOB2 能够在并行运行时，驱动三个主机上的 I/O 总量超过 30,000 MiB/秒。

集体顺序吞吐量的堆积条形图。

实际性能

在使用 SLOB2 测试了扩展限制之后，使用真实的供应链应用程序套件对 Azure NetApp 文件上的 Oracle 进行了测试，结果非常出色。 Oracle 自动工作负载存储库 (AWR) 报告的以下数据突出显示了如何执行特定的关键作业。

由于启用了闪回功能，除了应用程序工作负载之外，该数据库还产生了大量的额外 I/O，并且数据库块大小为 16k。 从 AWR 报告的 IO 配置文件部分来看，与读取相比，写入比率很大。

- 每秒读取和写入数 每秒读取数 每秒写入数
总计 (MB) 4,988.1 1,395.2 3,592.9

尽管 DB 文件顺序读取等待事件显示的延迟为 2.2 毫秒，高于 SLOB2 测试中的延迟，但这位客户发现，与 Exadata 上的 RAC 数据库相比，Azure 中的单一实例数据库在作业执行时间上缩短了十五分钟。

Azure 资源约束

所有系统最终都会遇到资源限制，这通常被称为瓶颈。 数据库工作负载，特别是资源需求较高的工作负载，如供应链应用程序套件，是资源密集型的实体。 找到并解决这些资源约束对于任何成功的部署都至关重要。 本节将阐明你可能在这种环境中遇到的各种约束，以及如何解决这些约束。 在每个小节中，你将了解最佳实践和它们背后的基本原理。

虚拟机

本节详细说明了在选择 VM 以实现最佳性能时需要考虑的标准，以及测试中做出选择的理由。 Azure NetApp 文件是一项网络附加存储 (NAS) 服务，因此适当的网络带宽配置对于实现最佳性能至关重要。

芯片组

感兴趣的第一个主题是芯片组选择。 出于一致性原因，请确保你选择的任何 VM SKU 都基于单个芯片集构建。 E_v5 VM 的 Intel 变体在第三代 Intel Xeon Platinum 8370C (Ice Lake) 配置上运行。 此系列中的所有 VM 都配备了单个 100 Gbps 网络接口。 相比之下，以 E_v3 系列为例，它建立在四个独立的芯片组上，具有各种物理网络带宽。 E_v3 系列中使用的四种芯片组（Broadwell、Skylake、Cascade Lake、Haswell）具有不同的处理器速度，这会影响机器的性能特征。

认真阅读 Azure 计算文档，注意芯片组选项。 另请参阅 Azure NetApp 文件的 Azure VM SKU 最佳做法。 最好选择具有单个芯片组的 VM，以便获得最佳一致性。

可用网络带宽

了解虚拟机网络接口的可用带宽与应用于同一接口的计费带宽之间的差异非常重要。 当 Azure Compute 文档提到网络带宽限制时，这些限制仅适用于出口（写入）带宽。 入口（读取）流量不按流量计费，因此仅受 NIC 本身物理带宽的限制。 大多数虚拟机的网络带宽超过了针对计算机应用的流出量限制。

由于 Azure NetApp 文件卷是网络连接的，因此可以将流出量限制定义为针对写入应用，而流入量定义为读取和类似读取的工作负载。 虽然大多数机器的流出量限制大于 NIC 的网络带宽，但对于本文测试中使用的 E104_v5 来说，情况并非如此。 E104_v5 具有 100 Gbps NIC，流出量限制也设置为 100 Gbps。 相比之下，具有 100 Gbps NIC 的 E96_v5 的流出量限制为 35 Gbps，而流入量则不受限制，为 100 Gbps。 随着虚拟机的减小，流出量限制会减少，但流入量仍不受逻辑限制的影响。

流出量限制是 VM 范围的，针对所有基于网络的工作负载应用此类限制。 当使用 Oracle Data Guard 时，所有写入操作都会复制到存档日志中，并且必须考虑流出量限制因素。 对于具有多目标和 RMAN 的存档日志（如有使用）也是如此。 选择虚拟机时，请熟悉 ethtool 等命令行工具，这将公开 NIC 的配置，因为 Azure 不会记录网络接口配置。

网络并发

Azure VM 和 Azure NetApp 文件卷配备了特定的带宽量。 如前所述，只要 VM 有足够的 CPU 空余空间，理论上工作负载就可以使用提供给它的带宽，即在网卡的限制内或应用了流出量限制。 但在实践中，可实现的吞吐量取决于网络工作负载的并发性，即网络流和网络终结点的数量。

阅读 VM 网络带宽文档的网络流限制部分，以加深了解。 要点：客户端与存储之间的网络流量越密集，潜在性能就越高。

Oracle 支持两个单独的 NFS 客户端：Kernel NFS 和 Direct NFS (dNFS)。 直到最近，Kernel NFS 还只支持两个端点（计算 - 存储）之间的单一网络流量。 Direct NFS（两者的性能更佳者）支持可变数量的网络流 - 测试显示每个端点有数百个独特的连接 - 根据负载需求增加或减少。 由于两个终结点之间的网络流缩放，Direct NFS 远优于 Kernel NFS，因此建议使用此配置。 Azure NetApp 文件产品组不建议将 Kernel NFS 用于 Oracle 工作负载。 有关详细信息，请参阅将 Azure NetApp 文件与 Oracle Database 配合使用的好处。

执行并发

利用 Direct NFS、单个芯片组保持一致性以及了解网络带宽约束，只能达到这个程度。 最终是应用程序驱动性能。 使用 SLOB2 进行的概念验证以及使用真实供应链应用程序套件对真实客户数据进行的概念验证之所以能够驱动大量的吞吐量，是因为这些应用程序以高并发度运行；前者每个模式使用大量线程，后者从多个应用服务器使用多个连接。 简而言之，并发性驱动工作负载，低并发性导致低吞吐量，高并发性导致高吞吐量，只要基础设施能够支持这一点。

加速网络

使用加速网络可以实现对 VM 的单根 I/O 虚拟化 (SR-IOV)，大幅提升其网络性能。 这种高性能路径会绕过数据路径中的主机，为受支持 VM 类型上最苛刻的网络工作负载降低延迟、抖动和 CPU 利用率。 通过配置管理实用工具（如 terraform 或命令行）部署 VM 时，请注意，默认情况下未启用加速网络。 为了获得最佳性能，请启用加速网络。 请注意，加速网络是根据网络接口来启用或禁用的。 加速网络功能是可以动态启用或禁用的一项。

注意

本文包含对术语 SLAVE 的引用，Microsoft 不再使用该术语。 在从软件中删除该术语后，我们会将其从本文中删除。

为 NIC 启用随后加速网络的权威方法是通过 Linux 终端实现的。 如果为 NIC 启用了加速网络，则第二个虚拟 NIC 与第一个 NIC 相关联。 第二个 NIC 由启用了 SLAVE 标志的系统配置。 如果没有具有 SLAVE 标志的 NIC，则不会为该接口启用加速网络。

在配置多个 NIC 的情况下，需要确定与用于装载 NFS 卷的 NIC 关联的 SLAVE 接口。 将网络接口卡添加到 VM 不会影响性能。

使用以下过程确定配置的网络接口与其关联的虚拟接口之间的映射。 此过程验证是否为 Linux 计算机上的特定 NIC 启用了加速网络，并显示 NIC 可能会实现的物理入口速度。

  1. 执行 ip a 命令：ip a 命令输出的屏幕截图。
  2. 列出要验证的 NIC ID 的 /sys/class/net/ 目录（示例中的 eth0）和用于“lower”一词的 grep：
    ls /sys/class/net/eth0 | grep lower lower_eth1
  3. 对在上一步中标识为较低设备的以太网设备执行 ethtool 命令。 eth1 设置输出的屏幕截图。

Azure VM：网络与磁盘带宽限制

阅读 Azure VM 性能限制文档时，需要具备一定程度的专业知识。 请注意：

  • 临时存储吞吐量和 IOPS 数值指的是直接连接到虚拟机的临时本地存储的性能。
  • 未缓存磁盘吞吐量和 I/O 数值特指 Azure 磁盘（Premium、Premium v2 和 Ultra），与网络附加存储（如 Azure NetApp 文件）无关。
  • 向虚拟机附加额外的 NIC 不会对虚拟机的性能限制或性能产生影响（已有文档记录并通过测试验证）。
  • 最大网络带宽指的是应用于虚拟机网络带宽的流出量限制（即当涉及 Azure NetApp 文件时的写入操作）。 未应用流入量限制（即应用 Azure NetApp 文件时读取）。 在拥有足够的 CPU、足够的网络并发性以及足够丰富的端点的情况下，理论上虚拟机可以将入口流量驱动到网络接口的极限。 如可用网络带宽部分所述，请使用 ethtool 等工具查看 NIC 的带宽。

示例图表如下所示：

显示示例图表数据的表的屏幕截图。

Azure NetApp 文件

Azure 自家的存储服务 Azure NetApp 文件提供了一种高度可用的全托管存储解决方案，能够支持前面介绍的具有挑战性的 Oracle 工作负载。

由于 Oracle 数据库中扩展存储性能的限制已经得到很好的理解，因此本文特意关注扩展存储性能。 横向扩展存储性能意味着为多个 Azure NetApp 文件卷提供单个 Oracle 实例访问权限，其中这些卷分布在多个存储终结点上。

通过以这种方式跨多个卷缩放数据库工作负载，数据库的性能不受卷和终结点上限的限制。 随着存储不再施加性能限制，虚拟机架构（CPU、NIC 和虚拟机出口限制）成为需要应对的瓶颈。 如 VM 部分所述，选择 E104ids_v5 和 E96ds_v5 实例时，请记住这一点。

无论数据库是放置在单个大型容量卷上还是分散在多个较小的卷上，总财务成本都是相同的。 与单个卷和终结点相比，跨多个卷和终结点分配 I/O 的优点是避免带宽限制，因此可以完全使用付费内容。

重要

若要在 multiple volume:multiple endpoint 配置中使用 Azure NetApp 文件进行部署，请联系 Azure NetApp 文件专家或云解决方案架构师以获取帮助。

数据库

Oracle 数据库的 19c 版本是 Oracle 当前的长期支持版本，也是本文中讨论的所有测试结果的生成版本。

为了获得最佳性能，建议使用 Direct NFS 装载所有数据库卷，因为性能约束，建议使用 Kernel NFS。 有关两个客户端之间的性能比较，请参阅 Azure NetApp 文件单卷上的 Oracle 数据库性能。 请注意，已应用了所有相关的 dNFS补丁（Oracle 支持 ID 1495104），并遵循了使用 Azure NetApp 文件在 Microsoft Azure 上运行 Oracle 数据库报告中概述的最佳实践。

尽管 Oracle 和 Azure NetApp 文件同时支持 NFSv3 和 NFSv4.1，但由于 NFSv3 协议更为成熟，通常认为它拥有最高的稳定性，因此对于高度敏感于中断的环境来说，它是一个更可靠的选择。 本文中所述的测试全部通过 NFSv3 完成。

重要

Oracle 在支持 ID 1495104 中记录的一些建议补丁对于在使用 dNFS 时保持数据完整性至关重要。 强烈建议对生产环境应用此类补丁。

NFS 卷支持自动存储管理 (ASM)。 尽管 ASM 通常与基于块的存储相关联，用于替代逻辑卷管理 (LVM) 和文件系统，但在多卷 NFS 场景中，ASM 发挥着重要作用，值得重点考虑。 ASM 的一个优势在于，它支持动态在线添加新加入的 NFS 卷和端点，并在它们之间重新平衡，从而简化了管理，允许根据需要扩展性能和容量。 尽管 ASM 本身并不提高数据库的性能，但它的使用避免了热点文件以及手动维护文件分布的需求 - 这是一个显而易见的优点。

本文中讨论的所有测试结果都是使用 dNFS 上的 ASM 配置生成的。 以下图表展示了 Azure NetApp 文件卷中的 ASM 文件布局以及文件到 ASM 磁盘组的分配情况。

Oracle 自动存储管理与 Azure NetApp 文件的示意图。

在使用通过 Azure NetApp 文件 NFS 挂载的卷上的 ASM 时，存储快照方面存在一些限制，但可以通过某些架构考虑因素来克服。 请联系 Azure NetApp 文件专家或云解决方案架构师，深入了解这些注意事项。

综合测试工具和可调参数

本部分介绍具体内容中的测试体系结构、可调参数和配置详细信息。 虽然上一部分侧重于配置决定的原因，但本部分重点介绍配置决定的“内容”。

自动化部署

  • 数据库 VM 是使用 GitHub 上提供的 bash 脚本部署的。
  • 手动完成多个 Azure NetApp 文件卷和终结点的布局和分配。 需要与 Azure NetApp 文件专家或云解决方案架构师合作以获取帮助。
  • 每台计算机上的网格安装、ASM 配置、数据库创建和配置以及 SLOB2 环境都使用 Ansible 进行配置，以确保一致性。
  • 多个主机上的并行 SLOB2 测试执行也使用 Ansible 来完成，以确保一致性和同时执行。

VM 配置

配置 值
Azure 区域 西欧
VM SKU E104ids_v5
NIC 计数 1 注意：添加 vNIC 对系统计数没有影响
最大出口网络带宽 (Mbps) 100,000
临时存储 (SSD) GiB 3,800

系统配置

所有 Oracle 所需的版本 19c 系统配置设置都根据 Oracle 文档实现。

以下参数已添加到 /etc/sysctl.conf Linux 系统文件中：

  • sunrpc.max_tcp_slot_table_entries: 128
  • sunrpc.tcp_slot_table_entries = 128

Azure NetApp 文件

所有 Azure NetApp 文件卷都装载了以下 NFS 装载选项。

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

数据库参数

参数 值
db_cache_size 2g
large_pool_size 2g
pga_aggregate_target 3g
pga_aggregate_limit 3g
sga_target 25g
shared_io_pool_size 500m
shared_pool_size 5g
db_files 500
filesystemio_options SETALL
job_queue_processes 0
db_flash_cache_size 0
_cursor_obsolete_threshold 130
_db_block_prefetch_limit 0
_db_block_prefetch_quota 0
_db_file_noncontig_mblock_read_count 0

SLOB2 配置

所有用于测试的工作负载生成都是通过 SLOB2 工具版本 2.5.4 完成的。

将 14 个 SLOB2 架构加载到标准 Oracle 表空间中并执行，结合列出的 slob 配置文件设置，使 SLOB2 数据集达到 7 TiB。 以下设置反映了 SLOB2 的随机读取执行。 在顺序测试期间，配置参数 SCAN_PCT=0 更改为 SCAN_PCT=100。

  • UPDATE_PCT=0
  • SCAN_PCT=0
  • RUN_TIME=600
  • SCALE=450G
  • SCAN_TABLE_SZ=50G
  • WORK_UNIT=32
  • REDO_STRESS=LITE
  • THREADS_PER_SCHEMA=1
  • DATABASE_STATISTICS_TYPE=awr

对于随机读取测试，执行了 9 次 SLOB2 执行。 从 1 开始，每次测试迭代都将线程数增加 6。

对于顺序测试，执行了 7 次 SLOB2 执行。 从 1 开始，每次测试迭代都将线程数增加 2。 由于达到网络带宽最大限制，线程计数上限为 6。

AWR 指标

所有性能指标都通过 Oracle 自动工作负载存储库 (AWR) 报告。 下面是结果中显示的指标：

  • 吞吐量：AWR 加载配置文件部分的平均读取吞吐量和写入吞吐量的总和
  • AWR 加载配置文件部分的平均读取 IO 请求数
  • AWR 前台等待事件部分中的 db 文件顺序读取等待事件平均等待时间

从专门设计的系统迁移到云

Oracle Exadata 是一个工程系统，是硬件和软件的组合，被认为是运行 Oracle 工作负载的最优化解决方案。 尽管云在技术世界的整体方案中具有显著优势，但对于那些已经阅读并了解 Oracle 围绕其特定工作负载所构建的优化的人来说，这些专用系统可能看起来极具吸引力。

在 Exadata 上运行 Oracle 时，选择 Exadata 有一些常见的原因：

  • 1-2 个高 I/O 工作负载非常适合 Exadata 的特性，并且由于这些工作负载需要显著的 Exadata 工程特性，因此与它们一起运行的其他数据库被整合到 Exadata 中。
  • 复杂或困难的 OLTP 工作负载需要 RAC 进行扩展，并且，如果没有对 Oracle 优化的深入了解，就难以使用专有硬件进行架构设计，或者可能存在无法优化的技术债务。
  • 未充分利用的现有 Exadata 承载了各种工作负载：这可能是由于之前的迁移、旧 Exadata 的停用，或者由于希望在内部使用/测试 Exadata。

从工作负载的角度理解从 Exadata 系统进行的任何迁移，以及迁移可能有多简单或多复杂，这一点至关重要。 另一个次要需求是从状态的角度理解购买 Exadata 的原因。 Exadata 和 RAC 技能的需求更高，这可能促使技术利益干系人推荐购买 Exadata。

重要

无论哪种情况，总体结论是，对于来自 Exadata 的任何数据库工作负载，使用的 Exadata 专有功能越多，迁移和规划就越复杂。 未充分利用 Exadata 专有功能的环境，有机会采用更简单的迁移和规划流程。

可以使用几种工具来评估这些工作负载机会：

  • 自动工作负载存储库 (AWR)：
    • 所有 Exadata 数据库都获得许可，可以使用 AWR 报告以及相关的性能和诊断功能。
    • 始终打开并收集数据，这些数据可用于查看历史工作负载信息并评估使用情况。 峰值可以评估系统上的高使用率，
    • 较大的窗口 AWR 报告可以评估整体工作负载，为功能使用情况和如何有效地将工作负载迁移到非 Exadata 环境提供有价值的见解。 相比之下，高峰期的 AWR 报告最适合用于性能优化和故障排查。
  • Exadata 的全局（RAC 感知）AWR 报告还包括一个针对 Exadata 的特定部分，该部分深入探讨了具体的 Exadata 功能使用情况，并提供了有关数据库和单元节点使用 Flash 缓存、Flash 日志、I/O 和其他功能的宝贵见解。

从 Exadata 分离

在识别要迁移到云端的 Oracle Exadata 工作负载时，请考虑以下问题和数据点：

  • 工作负载是否使用了多个 Exadata 功能，而不仅仅是硬件优势？
    • 智能扫描
    • 存储索引
    • 闪存缓存
    • 闪存日志记录
    • 混合列式压缩
  • 工作负载是否有效地使用了 Exadata 的卸载功能？ 在主要的前台事件耗时中，工作负载使用以下内容的比率（即超过 DB 总运行时间的 10%）是多少：
    • 单元格智能表扫描（最佳）
    • 单元格多块物理读取（次佳）
    • 单元格多块物理读取（最不佳）
  • 混合列式压缩 (HCC/EHCC)：压缩与未压缩的比率是多少：
    • 数据库是否花费超过 10% 的数据库时间来压缩和解压缩数据？
    • 检查查询中使用压缩的谓词性能提升情况：与通过压缩节省的空间相比，所获得的价值是否值得？
  • 单元物理 IO：检查下面带来的节省：
    • 定向到 DB 节点以平衡 CPU 的量。
    • 标识智能扫描返回的字节数。 一旦从 Exadata 迁移出去，这些值可以从 IO 中减去，以计算单元单块物理读取的百分比。
  • 记下缓存中的逻辑读取数。 确定在云 IaaS 解决方案中，该工作负载是否需要闪存缓存。
  • 将物理读写的总字节数与缓存中执行的总字节数进行比较。 是否可以通过增加内存来消除物理读取需求（为了强制 Exadata 进行卸载，有些人通常会减小 SGA 的大小）？
  • 在系统统计信息中，确定哪些对象受哪些统计信息的影响。 如果调整 SQL，进一步进行索引、分区或其他物理调优，可能会显著优化工作负载。
  • 检查初始化参数中的下划线 (_) 或已弃用的参数，这些参数需要得到合理的解释，因为它们可能会对数据库级别的性能造成影响。

Exadata 服务器配置

在 Oracle 版本 12.2 及更高版本中，AWR 全局报表中将包含特定于 Exadata 的新增功能。 此报表包含多个部分，为从 Exadata 的迁移提供了极高的价值。

  • Exadata 版本和系统详细信息

  • 单元节点警报详细信息

  • Exadata 非在线磁盘

  • 任何 Exadata OS 统计信息的离群值数据

    • 黄色/粉红色：值得关注。 Exadata 未以最佳方式运行。

    • 红色：Exadata 性能受到显著影响。

    • Exadata OS CPU 统计信息：顶部单元格

      • 这些统计数据由单元上的操作系统收集，并不局限于这个数据库或实例
      • v 和深黄色背景表示低于范围下限的离群值
      • ^ 和浅黄色背景表示高于范围上限的离群值
      • 按 CPU 百分比排序的前几个单元已显示，并按 CPU 百分比的降序排列
      • 平均：39.34% CPU、28.57% 用户、10.77% 系统

      按 CPU 百分比排序的顶部单元表格的屏幕截图。

  • 单个单元物理块读取

  • 闪存缓存使用情况

  • 临时 IO

  • 列式缓存效率

按 IO 吞吐量排序靠前的数据库

虽然可以进行规模评估，但对于大型工作负载，这些值中的平均值和模拟峰值存在一些疑问。 这个部分位于 AWR 报告的末尾，特别有价值，因为它显示了 Exadata 上前 10 个数据库的平均闪存和磁盘使用情况。 尽管许多人可能认为他们希望为云中的峰值性能调整数据库规模，但这对于大多数部署来说并不合理（超过 95% 的情况处于平均范围内；考虑到计算的模拟峰值，平均范围将大于 98%）。 为所需资源付费很重要，即使是 Oracle 需求最高的工作负载，检查按 I/O 吞吐量排序靠前的数据库对于了解数据库的资源需求也很有启发性。

在 Exadata 上使用 AWR 调整 Oracle 大小

在为本地系统进行容量规划时，在硬件中构建大量开销是很自然的事情。 无论是由于数据增长、代码更改或升级导致的工作负载增加，过度配置的硬件都需要在未来几年内为 Oracle 工作负载提供服务。

云的优点之一是可以随着需求的增长在虚拟机主机上扩展资源并进行存储。 这有助于节省附加到处理器使用情况的云成本和许可成本（与 Oracle 相关）。

适当的规模调整涉及从传统的迁移（提升和转移）中移除硬件，并使用 Oracle 的自动工作负载存储库 (AWR) 提供的工作负载信息，将工作负载提升和转移到专门为在客户选择的云中支持其而设计的计算和存储资源上。 适当的规模调整过程确保未来的架构能够消除基础设施的技术债务，避免在将本地系统复制到云时出现的架构冗余，并尽可能实现云服务。

Microsoft Oracle 主题专家估计，超过 80% 的 Oracle 数据库都过度预配，如果它们在迁移到云之前花时间对 Oracl e数据库工作负载进行适当的规模调整，那么迁移到云时的成本将保持不变或实现成本节约。 这项评估需要团队中的数据库专家转变他们过去可能进行容量规划的方式，但这对利益相关者在云中的投资和企业的云战略来说是值得的。

后续步骤