★ FEATURED ARTICLE 简介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。这里面最容易被忽视的一点是它的性能几乎随规模线性增长而不是堆了更多盘之后因为争用而打折。以 HCHigh Capacity存储节点为例Full Rack 的 SQL Flash 带宽是 630GB/sHalf Rack 是 315GB/sQuarter Rack 是 135GB/sEighth Rack 是 67.5GB/s逐级减半没有损耗。同样的规律也出现在 PMEM 读 IOPS 上Full Rack 的 2240 万次 8K 读Half Rack 算下来正好约 1120 万次。指标HC 存储节点Full RackHalf RackQuarter RackEighth Rack最大 SQL 闪存带宽630 GB/s315 GB/s135 GB/s67.5 GB/s最大 SQL PMEM 读 IOPS22,400,00011,200,0005,600,0002,800,000最大 SQL 闪存写 IOPS8,569,0004,298,0001,842,000921,000最大 SQL 磁盘带宽25 GB/s12.5 GB/s5.4 GB/s2.7 GB/s最大数据加载速率35 TB/hour17.5 TB/hour7.5 TB/hour3.8 TB/hour第一列的数字是很多人选型时的参考基准。两个容易误读的地方说明一下一是写 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 NVMeEF 是 8 块 6.4TB NVMeXT 则降到单 CPU、96GB 内存、无 PMEM只有 12 块 18TB HDD 和 2 块 240GB M.2 启动盘。存储节点型号CPU内存持久内存闪存硬盘HC2×16 核 Xeon 8352Y256 GB12×128 GB4×6.4 TB NVMe12×18 TBEF2×16 核 Xeon 8352Y256 GB12×128 GB8×6.4 TB NVMe无XT1×16 核 Xeon 8352Y96 GB无无12×18 TB1/8 机架 HC2×16 核 Xeon 8352Y256 GB6×128 GB2×6.4 TB NVMe6×18 TB最容易看漏的是最后一行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 机架23和满配214两种固定组合弹性时最多 3 个计算节点、14 个存储节点。机架顶部预留了 2U 空间给客户放自己的交换机这是很多人忽略的。如果你要用现有万兆网络做客户端接入这 2U 正好放一台接入交换机不用另占机柜位。内部 RoCE 网络则要求全冗余自带双交换机和冗余电源不需要额外采购网络设备。3.4 X9M 与 X8M 的代际差异升级换来了什么对比上一代 X8MX9M-2 计算节点的核心数从 24 核升到 32 核内存通道从 6 条 2600MT/s 升到 8 条 3200MT/sRoCE 网卡从 PCIe Gen3 升到 Gen4带宽是原来的 1.8 倍。本地盘变化最明显X8M 是 4 块或 8 块 1.2TB SAS HDDX9M 换成 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.2X9M 的准入门槛X9M 硬件只支持 Exadata System Software 21.2 及以上版本这是硬性门槛不是“建议升级”。原因很简单21.2 才包含对 Ice Lake 处理器、PCIe4.0 NVMe 卡和第二代持久内存的驱动与微码支持。你拿到一台 X9M 机器如果系统软件版本低于 21.2存储节点根本起不来或者能起来但 PMEM 和 RoCE 加速不生效。Exadata 硬件最低 Exadata 系统软件版本X9M21.2.0.0.0 或更高X8M19.3.0.0.0 或更高X819.2.0.0.0 或更高X718.1.0.0.0 或更高X612.1.2.3.1 或更高X5-212.1.2.1.0 或更高X5-812.1.2.2.0 或更高这里面有个容易被忽略的细节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 以上只满足最低启动版本是不够的。Oracle 数据库版本Exadata 系统软件最低要求完整 offload 功能要求21c21.2.0.0.0 或更高同最低要求19c19.1.2.0.0 或更高建议 19.1.6.0.0 以上18c18.1.4.0.0推荐 18.1.6.0.0 以上12.212.1.2.2.112.2.1.1.0 以上12.1.0.211.2.3.3.112.1.1.1.0 以上11.2.0.411.2.3.2.1需包含 Bug 13245134 修复另一个容易踩的点是 11.2.0.4 数据库。它虽然被支持但数据库 home 里必须安装修复 Bug 13245134 的补丁否则在 Exadata 上可能出现异常行为。很多团队把 X8M 的数据库版本直接带着升级到 X9M结果 Exadata 软件升到 21.2 后11.2.0.4 的数据库和存储节点通信异常最后查半天发现是旧补丁没打全。我的习惯是任何版本变更前先把数据库补丁刷到对应季度最新再动 Exadata 软件。4.3 从 X8M 升级到 X9M 的检查动作升级路径上我一般会按这个顺序走确认目标机型的 Exadata 软件版本满足硬件要求X9M 必须 21.2 起步。核对数据库版本在官方支持矩阵里并检查是否包含已知必要补丁。用dcli批量导出所有存储节点的当前配置包括 ASM 磁盘组信息、存储节点告警和 PMEM 状态。迁移前在 X9M 上搭一套同版本软件环境做一次 Smart Scan 和 redo 写入的基准测试留底用于上线后对比。停机窗口内先升级 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 替代 InfiniBandRoCE 依赖以太网无损特性需要在交换机上正确配置 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 diskTypeFlashDisk 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, statusstatus字段为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, metricValueCD_CPU_UTIL是 cellsrv 进程的 CPU 利用率正常情况下应在 40% 以下超过 60% 要开始关注持续超过 80% 就要考虑把部分扫描型负载分流到其他机架。配套还要看两个值CD_IO_UTILIO 利用率和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 产品介绍资料整理了各机架配置的详细参数拿去做选型和版本核对都合适。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
