Oracle数据库RAC集群由多个实例共同访问同一套共享存储，存储子系统的性能直接决定集群整体吞吐与稳定性。不同于单机数据库，RAC环境中所有节点通过私网进行全局缓存融合，任何存储层的延迟抖动都会被放大为跨节点等待。因此，在上线前或存储扩容前，必须对RAC集群背后的存储做系统化性能测试，而不是只信厂商标称的IOPS数值。
明确RAC存储性能测试的核心目标
很多团队做存储测试时习惯直接拿dd命令去写文件，认为顺序带宽高就代表存储好。但在Oracle RAC场景下，这种认知存在明显偏差。RAC的redo日志、控制文件、数据文件都存放在ASM磁盘组里，真正的压力来自大量并发会话的小块随机读写，以及实例间传输块时产生的写放大。如果测试只覆盖大块顺序写，根本无法暴露控制器缓存命中率下降后的真实性能。
测试目标应当拆成三层。第一层是裸设备能力，即不依赖数据库，直接测磁盘或LUN的随机读、随机写、混合读写延迟与IOPS上限。第二层是ASM层适配，确认多路径软件、ASM磁盘组冗余策略没有带来额外开销。第三层是集群并发层，用真实SQL负载观察全局缓存等待与I/O等待的比例。只有三层都达标，才能说存储满足RAC要求。
此外，RAC私网和存储网往往共用物理交换机或HBA卡，测试时要记录网络排队对存储响应的影响。我们曾在某客户环境发现，当私网心跳流量增加时，存储写延迟从2毫秒升到9毫秒，原因是网卡中断与HBA中断争用CPU。这类问题只有把集群组件都跑起来才能测出。
常用测试工具与具体实施方法
Oracle官方提供了Orion工具，它专为模拟Oracle数据库I/O模式设计，不需要安装数据库就能测。Orion可以定义随机读写比例、块大小、并发度，并直接输出不同负载下的IOPS和延迟曲线。对于ASM使用的裸设备，先用地图文件指定LUN路径，再运行混合负载测试。
下面是一个Orion测试的简化配置文件与调用示例，用于模拟8K块大小、70%读30%写的OLTP模式：
# orion.lun文件内容，列出待测试裸设备 /dev/mapper/asm_data01 /dev/mapper/asm_data02 # 执行命令 orion -run advanced -testname rac_storage -num_disks 2 -size_small 8 -type rand -readpct 70 -duration 60 -matrix basic
当裸设备测试通过后，应使用SLOB（Silent Load Generator）在真实RAC上产生逻辑I/O。SLOB通过大量扫描索引和表来制造物理读与写，能够触发ASM与缓存融合。部署时每个节点都启动SLOB实例，统一用同一套用户模式，观察AWR报告中gc buffer busy与db file sequential read的等待时间。如果存储跟不上，后者的平均等待会远超1毫秒。
另一种轻量做法是使用Oracle自带的DBMS_RESOURCE_MANAGER.CALIBRATE_IO过程，它直接在数据库内校准存储。不过该过程会占用大量I/O，只能在维护窗口跑。示例如下：
BEGIN
DBMS_RESOURCE_MANAGER.CALIBRATE_IO(
num_physical_disks => 4,
max_latency => 10,
max_iops => :iops,
max_mbps => :mbps,
actual_latency => :lat
);
END;
/
测试结果解读与常见误区规避
拿到测试数据后，不能只盯着峰值IOPS。RAC环境中更关键的是尾延迟，即99百分位写延迟。因为redo写入是同步操作，一旦存储偶发慢，就会阻塞整个实例的提交。我们用Orion输出观察，某存储标称8000 IOPS，但99%延迟达到20毫秒，这种设备在RAC中反而比稳定5000 IOPS、延迟全在2毫秒内的设备更危险。
另一个误区是忽略ASM冗余策略的代价。当磁盘组使用high冗余（三副本）时，每一次写都要落三个位置，存储控制器的写缓存若不足，性能会断崖式下跌。测试时必须用与生产相同的冗余级别，否则数据毫无参考性。同时，多路径软件的轮询策略也会影响并发度，使用round-robin和fixed在双控存储上差异可达15%。
最后，不要脱离集群做单节点测试就下结论。RAC的锁和全局资源目录会让两个节点同时写相邻块时产生额外的授权消息，这本身也会消耗存储带宽。正确方式是两个节点同时跑SLOB，且故意让业务有交叉数据访问，才能看到真实瓶颈。若发现跨节点I/O等待过高，应协同存储厂商调整LUN分布，避免两节点热点集中到同一磁盘柜。
构建可重复的常态化测试流程
存储性能不是一次测试就永久有效。阵列固件升级、磁盘老化、扩容重构都会改变特性。建议把Orion基础测试写进巡检脚本，每季度在维护窗口自动跑一遍，将IOPS和延迟变化绘成趋势图。一旦随机写延迟环比上升超过30%，就触发深入排查。
对于核心RAC，可在测试环境用HammerDB模拟全量批处理，把存储响应作为变量，观察完成时间。这样在真正扩容前，就能用数据告诉领导：换哪类盘、加几个轴能换来多少小时跑批缩短。这种基于测试的论证，比单纯看配置清单靠谱得多。
总之，Oracle RAC的存储性能测试是一项系统工程，需要从裸设备到集群负载逐层验证，选用契合数据库模式的工具，并以尾延迟和并发争用为核心指标。避开单机思维与顺序带宽陷阱，才能让集群在真实业务中稳如磐石。
Oracle_RAC存储性能测试ASM修改时间：2026-08-17 15:18:41