V$ASM_DISK_IOSTAT是ASM磁盘I/O性能诊断首选视图，提供单盘级读写延迟（厘秒）、错误计数、软读率等细粒度实时统计，可精准定位慢盘、故障盘及缓存问题；V$ASM_DISK_STAT适用于普通存储，而V$ASM_DISK_IOSTAT_SPARSE专用于云/虚拟化稀疏盘，额外暴露存储等待时间以区分ASM处理与后端瓶颈。
直接看 v$asm_disk_iostat 和 v$asm_disk_stat，别只盯着awr里的“tablespace io stats”——它压根不反映asm磁盘组的真实i/o分布。
为什么AWR的Tablespace IO Stats对ASM诊断基本无效
AWR报告中“Tablespace IO Stats”按表空间聚合，而ASM磁盘组是底层存储抽象层，一个表空间的数据文件可能跨多个磁盘、甚至多个磁盘组。它的Av Rd(ms)是加权平均值，会掩盖单个慢盘（比如某块SSD故障后延迟飙到2000ms，但被其他3块正常盘拉低到50ms）。更关键的是：该部分统计不区分ASM内部读（如AU元数据访问）、缓存软读（PERCENT_SOFT_READS）、稀疏盘预分配开销等真实ASM行为。
- 真正要定位ASM瓶颈，必须下钻到磁盘/卷/IO路径粒度，而非数据库逻辑对象层级
- AWR中
Physical Read Total IO Requests Per Sec这类全局指标只能告诉你“有压力”，无法回答“哪块盘在拖后腿” - 如果
ASM IO for non-blocking poll等待高，说明问题在ASM与存储交互环节，AWR里根本没这个维度
V$ASM_DISK_IOSTAT：查单盘I/O延迟和错误的首选视图
这是ASM实例内存中实时维护的细粒度I/O统计，字段单位统一为厘秒（0.01秒），可直接算出毫秒级延迟：
-
AVG_READ_TIME=READ_TIME / READS * 10（毫秒），持续＞20ms（OLTP）或＞50ms（DSS）即需干预 -
READ_ERRS或WRITE_ERRS＞0，立刻检查HEADER_STATUS是否为PROVISIONED或FAILED -
PERCENT_SOFT_READS＜80%，说明ASM缓存命中差，可能因_asm_cache_size过小或热点数据未驻留 - 查询示例：
SELECT group_number, disk_number, ROUND((read_time/reads)*10,2) avg_read_ms, ROUND((write_time/writes)*10,2) avg_write_ms, read_errs, write_errs, percent_soft_reads FROM v$asm_disk_iostat WHERE reads > 0 AND writes > 0 ORDER BY avg_read_ms DESC;
V$ASM_DISK_STAT vs V$ASM_DISK_IOSTAT_SPARSE：选哪个取决于你的存储类型
普通本地盘、SAN LUN用V$ASM_DISK_STAT；云环境（AWS EBS gp3/io2）、VMware VMDK等精简配置存储，必须查V$ASM_DISK_IOSTAT_SPARSE——它额外暴露READ_TIME_WAIT（纯等待存储响应的时间），能区分是ASM处理慢还是后端存储卡住。
-
V$ASM_DISK_STAT的READ_TIME包含ASM内部调度+存储响应，无法拆分 -
V$ASM_DISK_IOSTAT_SPARSE中若READ_TIME_WAIT / READ_TIME＞70%，基本可断定是云存储IOPS配额耗尽或阵列队列深度超限 - RAC环境务必用
GV$前缀视图，并按INST_ID分组，避免误判某节点独占I/O
结合gv$asm_operation确认重平衡是否真在“干活”
当EST_MINUTES长期不降，先别急着调asm_power_limit。查gv$asm_operation看SOFR和EST_WORK是否变化：
-
STATE = 'EXECUTING'但SOFR = 0→ 磁盘状态异常（查v$asm_disk中STATE是否为OFFLINE） -
POWER列数值远低于你设的asm_power_limit→ 本次操作显式指定了POWER N，参数未覆盖 -
EST_RATE = 0→ I/O被阻塞，此时应立刻查v$session_wait中是否有enq: A-<em>contention</em>或ASM IO for non-blocking poll堆积
复杂点在于：这些视图的数据全在ASM实例内存中，重启即清零；且V$ASM_DISK_IOSTAT_SPARSE在非稀疏盘上返回空行——容易误以为“没数据”而非“不适用”。
