CALIBRATE_IO测不出真实I/O主因是ASM条带与业务模式不匹配：细粒度条带加剧OLTP小IO延迟，粗粒度条带割裂OLAP大顺序读，需结合v$asm_diskgroup、v$asm_template和asmcmd iostat验证并调整AU大小与模板。
calibrate_io 测不出真实 i/o？先确认 asm 条带是否匹配业务模式
直接用 DBMS_RESOURCE_MANAGER.CALIBRATE_IO 测 RAC 节点 I/O，结果偏低或报错，大概率不是存储本身慢，而是 ASM 条带配置和实际负载不匹配。这个过程只测当前节点 ASM 实例提交 I/O 的路径能力，条带设计不合理会放大延迟、压低吞吐，尤其在 OLTP 高并发小 IO 或 OLAP 大顺序读场景下。
为什么细粒度条带在 OLTP 下反而拖慢 I/O 延迟
Oracle 默认细粒度条带（128 KB × 8）适合分散随机写热点，但代价是：每次逻辑写可能触发跨多个磁盘的物理 IO，增加 HBA 和控制器排队压力。尤其当 AU 设置过小（如默认 1 MB），而业务 SQL 频繁更新小块数据时，CALIBRATE_IO 模拟的随机 IO 模式会放大这种碎片效应。
- 现象：调用返回
iops=0或latency > 50ms，但v$asm_disk_iostat显示单盘read_time正常 - 检查命令：
SELECT name, allocation_unit_size, type FROM v$asm_diskgroup WHERE name = 'DATA'; - 若
allocation_unit_size是 1048576（1 MB）且type = 'EXTERN'，又跑 OLTP，建议改用粗粒度（AU=4M 或 8M）并禁用细粒度模板 - 改法（需停业务窗口）：
ALTER DISKGROUP data SET ATTRIBUTE 'au_size'='4M';，之后重建数据文件
OLAP 类查询卡顿？别只看磁盘吞吐，先查条带宽度是否被“切碎”
大表全扫、物化视图刷新慢，CALIBRATE_IO 却显示 MBPS 很高——说明基准测试用的是理想连续读，而实际执行计划因条带太细，把一个 16 MB 的段切成了上百个 128 KB 片，分散在不同磁盘上，导致磁头寻道和多路径调度开销激增。
- 验证方式：
asmcmd iostat -G DATA --io对比small_read_reqs和large_read_reqs比值；若前者远高于后者，条带已成瓶颈 - 不要依赖
v$asm_file查文件条带属性——它不暴露模板级设置，得用：SELECT name, redundancy, striping FROM v$asm_template WHERE group_number = (SELECT group_number FROM v$asm_diskgroup WHERE name = 'DATA'); - 若发现
striping = 'FINE'且业务以大顺序读为主，应创建新模板：ALTER DISKGROUP data ADD TEMPLATE stp_coarse ATTRIBUTES (unprotected coarse);
执行 CALIBRATE_IO 前必须核对的三个 ASM 状态
跳过这三步，CALIBRATE_IO 结果毫无参考价值，甚至误导扩容决策。
-
SELECT name, state, type FROM v$asm_diskgroup—— 确保目标磁盘组state = 'MOUNTED'且type != 'EXTERN'（EXTERNAL REDUNDANCY 不支持网络存储，CALIBRATE_IO 会静默失败） -
SELECT path, header_status, mode_status FROM v$asm_disk WHERE group_number = (SELECT group_number FROM v$asm_diskgroup WHERE name = 'DATA')—— 所有磁盘header_status必须是MEMBER，出现CANDIDATE或PROVISIONED会导致过程报ORA-29532 -
SHOW PARAMETER asm_diskgroups—— 当前实例的asm_diskgroups参数必须显式包含待测磁盘组名，否则即使磁盘组已挂载，CALIBRATE_IO也视为不可见
条带不是越大越好，也不是越细越稳；它和 AU、冗余类型、底层存储缓存策略耦合极深。一次 CALIBRATE_IO 调用背后，真正要校准的从来不是磁盘，而是整个 I/O 路径上所有层的协同效率。
