如何测试RAC的I/O吞吐量_CALIBRATE_IO过程与ASM性能基准测试

CALIBRATE_IO在RAC环境下需单实例执行且仅测本地ASM路径，失败主因包括磁盘组未挂载、冗余类型不支持、权限不足或参数错误；真实性能应结合v$asm_disk_iostat和asmcmd iostat动态分析。

直接跑 DBMS_RESOURCE_MANAGER.CALIBRATE_IO 会失败？先看 ASM 磁盘组是否支持

oracle rac 环境下，calibrate_io 不是万能的——它只对数据库文件所在存储有效，而 asm 磁盘组必须启用 asm_diskgroups 中列出、且磁盘头状态为 mounted 的组。更关键的是：该过程底层依赖 orion 模式（模拟随机 i/o），但 asm 不暴露裸设备路径，所以它实际测的是 asm 实例通过 asmfd 或 asmlib 向底层存储提交 i/o 的能力，而非物理磁盘本身。

常见错误现象：ORA-29532: Java call terminated by uncaught Java exception: oracle.sysman.emSDK.emd.util.EMSystemException 或直接返回 0 的 iops 和 mbps 值。这通常是因为：

• 当前实例未在 ASM_DISKGROUPS 中配置目标磁盘组（比如只挂了 DATA，却想测 FRA）
• ASM 磁盘组使用了外部冗余（EXTERNAL REDUNDANCY），但底层存储是 NFS 或 CIFS —— CALIBRATE_IO 明确不支持网络文件系统
• 执行用户缺少 select_CATALOG_ROLE 或未授予 EXECUTE 权限给 DBMS_RESOURCE_MANAGER

CALIBRATE_IO 在 RAC 中必须单实例执行，且不能跨节点并行

这个过程不是 RAC-aware 的。即使你在节点 1 上发起调用，它也只测量该节点本地 ASM 实例通往存储的路径（包括 HBA、多路径软件、控制器缓存等）。其他节点的 I/O 路径完全不会被纳入统计，也不会触发跨节点协调。

使用场景很明确：你只想知道“此刻这个节点连这组 ASM 磁盘能跑出多少 IOPS”，而不是整个集群吞吐上限。所以：

• 务必在待评估的节点上以 SYS 用户连接本地实例（不要用 SCAN 地址或 TNS 别名）
• 避免在运行中切换实例角色（比如正在做 switchover）——过程会中断并报 ORA-03113: end-of-file on communication channel
• 参数 num_physical_disks 必须填真实值（可通过 SELECT name, total_mb FROM v$asm_diskgroup 结合磁盘数量估算），填 0 会导致结果严重偏低

示例调用：

DECLARE   lat  INTEGER;   iops INTEGER;   mbps INTEGER; BEGIN   DBMS_RESOURCE_MANAGER.CALIBRATE_IO(     num_physical_disks => 8,     max_latency => 20,     iops => iops,     mbps => mbps,     latency => lat   );   DBMS_OUTPUT.PUT_LINE('IOPS=' || iops || ' MBPS=' || mbps || ' Latency=' || lat); END;

真正反映 ASM 性能瓶颈的，其实是 v$asm_disk_iostat 和 asmcmd iostat

CALIBRATE_IO 是个“快照式”压力测试，但 ASM 的真实负载波动大、模式复杂（比如 Rebalance、DG 重建、大量归档写入）。这时候静态基准意义有限，动态指标更管用。

重点看两个地方：

• v$asm_disk_iostat 中的 read_time/write_time 除以 reads/writes 得到平均单次 I/O 延迟（单位 ms），超过 15ms 就该怀疑链路或磁盘问题
• asmcmd iostat -G DATA --io（12c+）能实时显示每个磁盘的 IOPS、MBPS、await，比 sql 视图更直观；注意加 --io 否则只显示容量信息
• 如果发现某块磁盘 await 高但 %util 低，大概率是多路径策略不当或 HBA 队列深度设得太小

别拿 CALIBRATE_IO 结果去调优 ASM 冗余级别或条带化

这个过程测的是“当前配置下的综合吞吐”，不是“理论最大吞吐”。它无法区分是 ASM 条带（ASM_POWER_LIMIT）、磁盘故障域（failure group）、还是底层 RAID 卡缓存策略导致的瓶颈。

容易踩的坑：

• 在 NORMAL 冗余磁盘组上跑出高 IOPS，就以为可以关掉镜像写优化——错。CALIBRATE_IO 不模拟双写路径，实际业务写入时镜像同步会吃掉额外延迟
• 把单节点结果当成 RAC 全局能力，然后据此扩容存储——危险。RAC 下多个实例并发写同一磁盘组，锁争用和 ASM 分配器竞争会让真实吞吐远低于单节点峰值
• 忽略 asm_power_limit 对测试的影响：设成 0（禁用 rebalance）时结果偏高，但生产环境不可能长期关闭；设成默认 1，则 rebalance 期间 I/O 干扰不可忽视

真要定位 ASM 存储瓶颈，得结合 AWR 报告里的 ASM file access statistics、Cell Offload Efficiency（如果是 Exadata），再配合存储厂商工具（如 Dell PowerStore 的 perfstat 或 NetApp 的 sysstat）交叉验证。