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）交叉验证。
