简介：Oracle Exadata x9m产品介绍PPT，面向数据库管理员、架构师及企业IT决策者，系统梳理Exadata x9m作为Oracle数据库专用工程化系统的定位与核心价值。内容覆盖产品在OLTP、数据仓库、内存分析等场景下的性能表现、硬件配置和关键参数，并给出全架、半架、四分之一架、八分之一架配置下的SQL闪存带宽、PMEM读写IOPS、数据加载速率等指标，便于读者快速评估与选型。资源包共1个文件，为57.17MB的PPTX演示文稿，适合内部培训、方案汇报或技术学习，已有230人学习。演示文稿还重点呈现Exadata X9M与Dell EMC PowerMax 8000在吞吐量、IOPS、延迟上的对比，以及Exadata在金融服务、医疗、零售等行业的采用情况，包括财富100强企业87%的使用占比；同时结合“五个九”高可用性和IDC商业价值研究，帮助读者从产品特性、竞品差异、行业实践与运维效益多个维度理解Exadata x9m。

1. 为什么数据库跑在 Exadata X9M 上，会和普通服务器差一个数量级

做数据库选型的人第一次看到 Exadata X9M 的性能表，多半会愣一下：一个标准机架能跑出 2760 万次 8K 读 IOPS、1TB/s 的分析扫描带宽、19 微秒的 SQL 读延迟。这不是“多塞几块闪存盘”能堆出来的数字，而是把数据库软件、存储软件和硬件绑在一起协同设计的结果。X9M 是 Exadata 的第十一代产品，2021 年发布，距第一代 V1 已经过了十多年。它解决的核心问题很直接：让 Oracle 数据库在 OLTP、数据仓库、数据库整合和内存分析这几类负载下，不用改应用就能获得远高于通用服务器的性能和可用性。适合谁看？打算采购或升级数据库一体机、正在做 X8M 存量评估、或者想搞清楚 Exadata 性能参数为什么这么写的架构师和 DBA，这份资料都值得过一遍。

2. 拆解性能指标：带宽、IOPS 与延迟背后不是堆硬件而是数据路径优化

2.1 先读总表：从机架比例看懂吞吐和 IOPS 的线性扩展

Exadata 的性能表按机架比例给出，从 Eighth Rack 到 Full Rack。这里面最容易被忽视的一点是，它的性能几乎随规模线性增长，而不是堆了更多盘之后因为争用而打折。以 HC（High Capacity）存储节点为例，Full Rack 的 SQL Flash 带宽是 630GB/s，Half Rack 是 315GB/s，Quarter Rack 是 135GB/s，Eighth Rack 是 67.5GB/s，逐级减半，没有损耗。同样的规律也出现在 PMEM 读 IOPS 上：Full Rack 的 2240 万次 8K 读，Half Rack 算下来正好约 1120 万次。

第一列的数字是很多人选型时的参考基准。两个容易误读的地方说明一下：一是写 IOPS 是在 ASM 镜像之后于存储服务器侧测的，也就是说已经计入冗余副本的写放大，不是应用侧看到的裸写 IOPS；二是加载速率通常会受数据库服务器 CPU 限制，而不是存储上限，所以 35TB/hour 是理想峰值，实际跑批量加载时先看计算节点够不够。

2.2 HC、EF 和 XT：高容量、极速闪存与扩展存储的取舍

Exadata 存储服务器按盘型分成三类。HC 是 12 块 18TB 7200 转 HDD 加 4 块 NVMe 闪存卡，适合容量敏感、有一定热数据的场景；EF 是 8 块 NVMe 闪存卡、不带 HDD，适合追求极致 IOPS 和低延迟的 OLTP 场景；XT 是纯扩展盘柜，只有硬盘没有闪存，适合做归档和冷数据分层。这三类节点在同一个机架里可以混用，Exadata 会把热块自动放到闪存、冷数据留在 HDD，不需要应用干预。

选型时别只看单块盘容量。EF 节点虽然单机容量小，但每个节点有 8 块 6.4TB NVMe PCIe4.0 闪存卡，全闪节点在小 IO 随机读场景下几乎不受磁盘寻道影响；HC 节点如果 flash cache 命中率上不去，大批量扫描时还是会落到 HDD。XT 则更极端，它连 PMEM 都不配，只适合数据生命周期里“很少访问但不能丢”的部分。常见做法是把热表和索引放到 EF 或 HC 的闪存层，把历史分区表放到 XT，再配合分区裁剪让查询不碰冷数据。

2.3 Smart Scan 与存储索引：参数表读不出来的数据库感知能力

Exadata 真正拉开差距的，不是那几块 NVMe，而是存储节点上的智能扫描软件。传统架构里，数据库把数据页从存储读回数据库服务器内存，再由 CPU 过滤行和列；Exadata 的 Smart Scan 会在存储节点上直接做谓词判断和列裁剪，只把符合条件的行、需要的列返回给计算节点。如果表经过混合列压缩，扫描时甚至能在压缩态下做过滤，返回的数据量能少一个数量级。存储索引则是另一种“免费”优化：存储节点在内存里维护每个存储区域的最大值和最小值，查询条件落在区间之外时，整个区域的 IO 直接跳过。

判断 Smart Scan 是否生效，不要只看 SQL 跑得快不快。一个常见误用是拿包含 LOB 字段的查询做测试，或者对索引扫描执行计划做 offload 验证，结果发现没走 Cell 多路径就认为功能有问题。Smart Scan 主要覆盖全表扫描、分区扫描和索引快速全扫描，点查走 B-Tree 索引时本来就不会切到智能扫描路径，这是设计行为，不是故障。

2.4 为什么 19 微秒延迟能出现：RDMA 与 PMEM 的配合

Exadata 从 X8M 这一代引入 PMEM（持久内存）和 RoCE 网络，X9M 把它推进到 PCIe4.0 和 100Gb/s RDMA。RDMA 的意思是，一台服务器可以不经过操作系统协议栈和远程 CPU，直接通过网卡读写另一台服务器的内存。Exadata 把数据库日志写和块传输放到这条路径上，redo 写入延迟被压到很低的水平，这也是 8K SQL read 能达到 19 微秒延迟的关键。因为普通网络存储的延迟大头都花在协议解析和上下文切换上，RoCE + RDMA 把这条路缩短成了网卡直通。

这套机制对上层透明，但底层依赖无损网络。RoCE 本质上是以太网上的 RDMA，一旦网络里出现丢包，重传惩罚远高于传统 TCP，性能曲线会瞬间崩塌。所以 X9M 对交换机的 PFC（优先级流控）和 ECN 配置有严格要求，安装时这些参数如果不对，就会出现“单机测速正常、集群跑起来延迟暴涨”的玄学问题。第 5 章会专门讲这个坑。

3. 硬件规格与选型：X9M-2、X9M-8 和三种存储节点怎么配

3.1 计算节点选型：两路还是八路

X9M 的计算节点分 X9M-2 和 X9M-8 两条线。X9M-2 是两路插槽，配 2 颗 32 核 Ice Lake 8358 处理器（2.6GHz），默认 512GB 内存、可扩到 2TB；本地盘是 2 块 3.84TB NVMe SSD，可按需扩到 4 块。X9M-8 是八路插槽，配 8 颗 24 核 8268 处理器（2.9GHz），默认 3TB 内存、可扩到 6TB，本地是 2 块 6.4TB NVMe PCIe3.0 闪存卡。两者用途差异很明显：X9M-2 覆盖从 1/8 机架到满配的绝大多数场景，性价比高；X9M-8 面向单库极大内存需求，通常是超大实例整合或 SAP 类负载。

选两路还是八路，核心看两点。第一是数据库 SGA 需求有没有超过单台两路节点的寻址上限；第二是许可证成本，X9M-8 的 CPU 基数更大，Oracle 企业版按核授权时费用会明显高出。常见做法是优先用 X9M-2 横向扩展，单库实在顶不住再切 X9M-8，而不是一开始就上八路。

3.2 存储节点规格速查：HC、EF、XT 以及 1/8 机架的差异

三种存储节点里，HC 和 EF 都带 2 颗 16 核 Ice Lake 8352Y 处理器、256GB 内存和 12 条 128GB 第二代持久内存。区别在闪存和硬盘的配比：HC 是 12 块 18TB HDD + 4 块 6.4TB NVMe，EF 是 8 块 6.4TB NVMe；XT 则降到单 CPU、96GB 内存、无 PMEM，只有 12 块 18TB HDD 和 2 块 240GB M.2 启动盘。

最容易看漏的是最后一行：1/8 机架虽然也叫 HC 存储节点，但持久内存只有 6 条而不是 12 条，闪存卡 2 块、硬盘 6 块。也就是说，1/8 机架的 PMEM 加速能力只有标准 HC 的一半，如果业务对 redo 写入延迟敏感，起步配置别选 1/8 机架。

3.3 机架组合与弹性配置：从 1/8 到满配怎么组合

X9M-2 支持 1/8 机架、1/4 机架、1/2 机架（4 个计算节点 + 7 个存储节点）和满配（8 个计算节点 + 14 个存储节点）。满配整机架的容量上限是 3.8PB 原始磁盘、920TB NVMe 闪存和 27TB PMEM。除了固定比例，X9M-2 还支持弹性配置：以 1/4 机架为基础，计算节点最多扩到 19 个，存储节点最多扩到 18 个，存储和计算可以解耦扩容。X9M-8 则只有 1/2 机架（2+3）和满配（2+14）两种固定组合，弹性时最多 3 个计算节点、14 个存储节点。

机架顶部预留了 2U 空间给客户放自己的交换机，这是很多人忽略的。如果你要用现有万兆网络做客户端接入，这 2U 正好放一台接入交换机，不用另占机柜位。内部 RoCE 网络则要求全冗余，自带双交换机和冗余电源，不需要额外采购网络设备。

3.4 X9M 与 X8M 的代际差异：升级换来了什么

对比上一代 X8M，X9M-2 计算节点的核心数从 24 核升到 32 核，内存通道从 6 条 2600MT/s 升到 8 条 3200MT/s，RoCE 网卡从 PCIe Gen3 升到 Gen4，带宽是原来的 1.8 倍。本地盘变化最明显：X8M 是 4 块或 8 块 1.2TB SAS HDD，X9M 换成 2 块或 4 块 3.84TB NVMe SSD，可用容量相近，但随机性能完全不是一个量级。

存储节点方面，HC 的硬盘容量从 14TB 升到 18TB，单机容量增加 28%，内存从 192GB 升到 256GB，闪存卡从 PCIe Gen3 升到 Gen4。持久内存容量没变，但换成了第二代 Optane 系列。整体看，X9M 这代提升不靠重新发明架构，而是把 CPU、内存通道、PCIe 带宽和盘型全部换代，再叠加 21.2 版本系统软件的优化。

4. 版本对应关系：Exadata 软件、Oracle Database 和固件矩阵

4.1 Exadata System Software 21.2：X9M 的准入门槛

X9M 硬件只支持 Exadata System Software 21.2 及以上版本，这是硬性门槛，不是“建议升级”。原因很简单：21.2 才包含对 Ice Lake 处理器、PCIe4.0 NVMe 卡和第二代持久内存的驱动与微码支持。你拿到一台 X9M 机器，如果系统软件版本低于 21.2，存储节点根本起不来，或者能起来但 PMEM 和 RoCE 加速不生效。

这里面有个容易被忽略的细节：X8M 和 X9M 都走 RoCE 网络，而 X8 及更早型号走 InfiniBand，网络架构完全不同。做升级时不能把 X8 的存储节点直接搬到 X9M 机架里，必须按官方 RoCE 硬件要求重新配网。版本矩阵的具体细节以官方文档 2724126.1 为准，每次开工前先查一遍。

4.2 Oracle Database 版本与 offload 功能完整度

数据库版本和 Exadata 系统软件的匹配，决定了 Smart Scan、存储索引、IORM 等功能是否完整可用。比较典型的例子是 12.2 数据库：完整 offload 功能和 IORM 对 12.2 CDB/PDB 的支持，要求 Exadata 12.2.1.1.0 以上，只满足最低启动版本是不够的。

另一个容易踩的点是 11.2.0.4 数据库。它虽然被支持，但数据库 home 里必须安装修复 Bug 13245134 的补丁，否则在 Exadata 上可能出现异常行为。很多团队把 X8M 的数据库版本直接带着升级到 X9M，结果 Exadata 软件升到 21.2 后，11.2.0.4 的数据库和存储节点通信异常，最后查半天发现是旧补丁没打全。我的习惯是：任何版本变更前，先把数据库补丁刷到对应季度最新，再动 Exadata 软件。

4.3 从 X8M 升级到 X9M 的检查动作

升级路径上，我一般会按这个顺序走：

1. 确认目标机型的 Exadata 软件版本满足硬件要求，X9M 必须 21.2 起步。
2. 核对数据库版本在官方支持矩阵里，并检查是否包含已知必要补丁。
3. 用dcli批量导出所有存储节点的当前配置，包括 ASM 磁盘组信息、存储节点告警和 PMEM 状态。
4. 迁移前在 X9M 上搭一套同版本软件环境，做一次 Smart Scan 和 redo 写入的基准测试，留底用于上线后对比。
5. 停机窗口内先升级 Exadata 软件再迁移数据库，不要反过来。

这套动作里最容易省掉的是第 3 步，但存储节点告警和 PMEM 状态在升级前后不一致时，事后排查会非常被动。导出一份配置清单，等于给升级留了后悔药。

5. 性能翻车排查：X9M 投产前最容易踩的 5 类坑

5.1 持久内存容量算错：1/8 机架的 PMEM 只有一半

现象：按 1/8 机架采购的 X9M 到货后，发现持久内存容量是 768GB，而不是按“满配 27TB / 8”推算出来的 3.4TB 左右（其实满配 14 个 HC 存储节点 × 1.5TB PMEM 约 21TB，但 1/8 机架存储节点也少，不是简单除法）。

原因：1/8 机架的 HC 存储节点只配 6 条 128GB PMEM，而不是标准 HC 的 12 条；起步配置的闪存卡也只有 2 块。这是产品线的固定规格，不是安装事故。

解决：采购阶段直接按“1/8 机架 HC 存储节点 = 6×128GB PMEM + 2×6.4TB NVMe + 6×18TB HDD”来核对容量。如果业务依赖 PMEM 加速 redo 写入，1/8 机架起步时就要评估是否直接上 1/4 机架，否则后期补存储节点会牵动磁盘组平衡。

5.2 RoCE 网络丢包：RDMA 快的前提是无损以太网

现象：集群跑着跑着，AWR 里出现大量gc buffer lost或log file sync等待，IO 延迟从 20 微秒级跳到几毫秒级；单条 SQL 测试正常，并发一上来就崩。

原因：X9M 用 RoCE 替代 InfiniBand，RoCE 依赖以太网无损特性，需要在交换机上正确配置 PFC（优先级流控）和 ECN（显式拥塞通知）。很多数据中心的现网交换机没有开这些参数，或者连接端口接了不支持 PFC 的上联口，导致 RoCE 流量在拥塞时直接丢包。

解决：安装阶段要求网络团队按 Exadata RoCE 网络白皮书逐项核对交换机配置，重点看 PFC 优先级映射、ECN 水线和 DCBX 协商状态。排查时先看交换机端口的pause frame计数，如果持续增长，基本可以断定无损网络配置失效，先修网络再调数据库。

5.3 NVMe 闪存寿命：测试期就把盘写花了

现象：跑了一两个月压力测试，存储节点告警，cellcli查到某块 NVMe 盘的剩余寿命百分比明显下降，甚至触发介质预警。

原因：Exadata 的 NVMe 闪存要同时承担 flash cache 写和用户数据写，测试阶段如果并发跑大量随机写负载，写放大系数会被放大。更常见的是有人用dd或文件系统级工具直接对裸设备做全盘写测试，完全绕过了 Exadata 的 IO 管理，闪存寿命消耗极快。

解决：压测前用cellcli记录每块盘的寿命基线，压测期间打开 IORM 限制最大写吞吐，避免测试负载打满整机架。日常巡检里把闪存剩余寿命纳入监控，低于 30% 时提前备件，别等告警了才处理。

5.4 HCC 压缩率不达标：压缩级别选错

现象：表建好并做了混合列压缩，查实际占用发现只压缩了 2~3 倍，远低于宣传的 10 倍以上。

原因：HCC（混合列压缩）的压缩级别分QUERY LOW、QUERY HIGH、ARCHIVE LOW、ARCHIVE HIGH，级别越高压缩比越大，但写入开销也越高。OLTP 表如果选ARCHIVE HIGH，每次插入和更新都付出巨大 CPU 代价；反过来，分析场景如果只选了QUERY LOW，压缩率自然上不去。

解决：按数据温度选压缩策略——频繁更新的表用QUERY LOW，只读历史分区用ARCHIVE HIGH，并且用DBMS_COMPRESSION包先估算再决定。HCC 对更新和删除特别敏感，行一旦发生迁移，压缩比会明显下降，所以大表一定要配合分区设计和批量加载。

5.5 版本矩阵没查对：固件、软件和数据库版本冲突

现象：X9M 上装 19c 数据库，连接存储节点时报版本不兼容错误，或者 Smart Scan 不触发。

原因：最常见的是数据库 home 打了太旧的 RU，和 Exadata 21.2 系统软件没有匹配到官方矩阵；其次是 Grid Infrastructure 版本低于 18c，导致集群件无法正确调度 storage server IO。还有人在 X8M 的存储节点固件上直接跑 X9M 的 21.2 软件，固件和驱动不匹配，各种诡异告警。

解决：上线前把数据库版本、Grid Infrastructure、Exadata 系统软件、存储节点固件四条线的版本号列成表，逐项核对官方2724126.1文档。版本矩阵是 Exadata 运维里最不能靠经验的环节，查文档不丢人，拍脑袋才容易出事。

6. 用 CellCLI 做一轮投产前体检：三个必看指标

6.1 看闪存和持久内存的健康状态

投产前我习惯先在任意一台计算节点上用dcli批量跑 CellCLI，把整个存储网格的健康状态一次性拉出来。闪存寿命和介质状态是第一个必看项：

dcli -g cell_group -l root "cellcli -e list physicaldisk where diskType='FlashDisk' attributes name, percentFreeSpace, mediaStatus"

逻辑说明：dcli会按cell_group文件里的存储节点列表并发执行，cellcli -e表示非交互执行单条命令。percentFreeSpace表示闪存剩余寿命百分比，mediaStatus则直接给出介质是否正常。输出里如果出现critical状态，说明盘已经进入预警；同一批盘寿命差超过 10 个百分点，说明负载不均衡，要查一下 ASM 磁盘分布。持久内存的状态单独查：

dcli -g cell_group -l root "cellcli -e list pmemdisk attributes name, size, status"

status字段为normal才表示 PMEM 在线工作。如果一整套设备所有 PMEM 都显示normal，但 redo 写入延迟仍然高，下一步就要看网络而不是看盘。

6.2 看存储节点 CPU 和 I/O 响应时间

第二个必看是存储节点的 CPU 利用率，因为 Smart Scan 是在存储侧消耗 CPU 的，如果存储节点常年 80% 以上，应用侧再优化都没有用。用 CellCLI 的metriccurrent能直接看到实时指标：

cellcli -e list metriccurrent cellsrv where name like 'CD_CPU\_UTIL*' attributes name, metricValue

CD_CPU_UTIL是 cellsrv 进程的 CPU 利用率，正常情况下应在 40% 以下；超过 60% 要开始关注，持续超过 80% 就要考虑把部分扫描型负载分流到其他机架。配套还要看两个值：CD_IO_UTIL（IO 利用率）和CD_LATENCY（响应延迟）。这三项一起看，能快速区分瓶颈在 CPU 还是在存储介质。

6.3 验证 offload 到底有没有生效

第三个必看是验证 Smart Scan 是否真的在工作，而不是“看着像”。跑一条目标 SQL 后，在数据库里查这条 SQL 的监控视图：

select sql_id, io_cell_offload_eligible_bytes, io_cell_offload_returned_bytes from v$sql where sql_id = '目标SQL的SQL_ID';

逻辑说明：io_cell_offload_eligible_bytes是存储节点上符合 offload 条件的数据量，io_cell_offload_returned_bytes是实际返回给计算节点的数据量。如果 eligible 很大而 returned 很小，说明 Smart Scan 把大量数据过滤在了存储侧，这是最理想的状态；如果两个数差不多，说明 offload 几乎没有过滤效果，要回头查执行计划里是否出现了STORAGE FULL字样，以及查询条件有没有被写成无法下推的形式。另一个更简单的体检项是看全局统计：

select name, value from v$sysstat where name like 'cell physical IO bytes saved by storage index%';

这个值统计的是存储索引跳过 IO 节省的字节数。如果它长时间不增长，说明存储索引没有发挥作用，通常是扫描集中在刚写入的新数据区，还没来得及生成索引信息——不是故障，但值得留意。

说起来有点惭愧，早年间我接手一套性能诡异的 Exadata 环境，排查了两天最后发现是网络交换机 PFC 配置被运维重置过。从那以后，我每次项目验收前都强制走一遍这套体检流程：先看盘和 PMEM 健康，再看存储节点 CPU，最后跑一条真实 SQL 确认 offload 数字。流程不长，但足够把 80% 的隐性坑挡在上线之前。希望帮到你。整套 Exadata X9M 产品介绍资料整理了各机架配置的详细参数，拿去做选型和版本核对都合适。

本文还有配套的精品资源，点击获取