在Oracle RAC集群里，ASM（Automatic Storage Management）负责统一管理共享存储，当对磁盘组进行扩容、缩容或手工触发重平衡时，这些动作并不会瞬间完成，而是以后台进程逐步迁移数据的方式推进。此时数据库实例并不会直接报错或卡死，但从业务侧看可能感受到IO延迟波动。要掌握这类操作的实时进度，核心就是查询v$asm_operation这一动态性能视图。
v$asm_operation视图的字段结构与含义
v$asm_operation是ASM实例以及挂载了ASM磁盘组的数据库实例中均可查询的视图，它每一行代表一个正在进行的ASM磁盘组操作。最重要的字段包括group_number（磁盘组编号）、operation（操作类型，如REBAL、DROPDISK、ADDISK）、state（状态，常值为WAIT或RUNNING）、power（当前电源限制值）、actual_work（已完成的工作量，以操作单位计）、est_work（预估总工作量）、est_rate（预估处理速率）以及est_minutes（预估剩余分钟数）。
其中operation字段直接说明后台在做什么，state为RUNNING表示任务正在执行。actual_work与est_work的比值可以换算成完成百分比，但需要注意这两个值的单位依操作类型不同可能不是字节，而是ASM内部的分配单元计数。est_rate则结合est_work与actual_work能粗略推算剩余时间，不过在负载变化剧烈时预估值会跳动。理解这些字段是正确使用该视图的前提，不能只看est_minutes就认为绝对准确。
在RAC环境下，每个实例本地只看到自己实例发起或参与的ASM操作映射，如果操作由集群中的其他实例触发，本实例的v$asm_operation可能为空，此时应连接到操作发起节点或使用GV$ASM_OPERATION全局视图来跨实例观察。这也是很多运维误以为重平衡没启动、实则只是在错误节点查询的原因。
通过SQL实时计算重平衡进度
仅查询原始字段不够直观，通常我们会写成一条SQL，把工作量换算为百分比，并显示出预计结束时间。下面示例在ASM实例或具有相应权限的数据库会话中执行，利用est_work与actual_work算出进度，并用sysdate加est_minutes得到预计完成点。
SELECT group_number, operation, state, power, ROUND((actual_work / est_work) * 100, 2) AS pct_done, est_work, actual_work, est_rate, est_minutes, sysdate + (est_minutes / 1440) AS expected_finish FROM v$asm_operation WHERE est_work > 0;
上述查询在est_work大于0时才会算出比例，避免除零错误。如果查询返回空行，说明当前没有正在运行的ASM磁盘组操作，或者本实例并未参与。对GV$ASM_OPERATION使用类似语句时，可额外选出inst_id字段，以区分操作来自哪个实例。
有时重平衡因为电源限制（power）设得较低而非常缓慢，可以通过ALTER DISKGROUP ... REBALANCE POWER n语句动态调整。在观察v$asm_operation时，若发现est_rate长期偏低，可结合v$asm_disk看是否某些磁盘响应慢，再决定是否临时提升power或避开业务高峰。这样就把视图数据转化成了具体的运维决策。
与其他视图联合排查IO与进度异常
单看v$asm_operation容易孤立判断，实际排障时常把它和v$asm_diskgroup、v$asm_disk联用。v$asm_diskgroup给出磁盘组总大小、空闲量与冗余类型，v$asm_disk则列出每块盘的路径、状态与读写错误。当v$asm_operation显示RUNNING但pct_done长时间不变，就应检查v$asm_disk中是否有OFFLINE或ERROR状态的磁盘。
SELECT d.group_number, d.disk_number, d.path, d.state, d.total_mb, d.free_mb, o.operation, o.state AS op_state, ROUND((o.actual_work / o.est_work) * 100, 2) AS pct FROM v$asm_disk d LEFT JOIN v$asm_operation o ON d.group_number = o.group_number WHERE d.group_number = 1;
这段查询把磁盘清单和对应磁盘组的操作状态横向列出，能迅速定位是否某块盘拖慢了整体重平衡。在RAC中如果某节点对共享盘的访问路径存在多路径软件配置差异，也会表现为est_rate异常，此时视图数据是指引存储层排查的线索而非终点。
另外要注意权限问题：普通数据库用户默认无法查询v$asm_operation，需要用SYSASM或SYSDBA连接到ASM实例，或在数据库侧由管理员授权SELECT ANY DICTIONARY。缺乏权限时会报ORA-00942，容易被误认为集群没开ASM，实则是视图不可见。把权限、查询节点、联查视图三者结合起来，才能完整利用v$asm_operation监控RAC存储变更。
生产环境中安排变更窗口的建议
从实践看，ASM重平衡窗口应尽量避开批量交易或报表高峰。通过v$asm_operation观察可知，power值越高占用IO越多，但完成越快。通常生产环境设power为1到4之间，既控制影响又保证数小时内收尾。若必须在白天操作，建议每半小时查一次pct_done与est_minutes，绘制简易进度曲线。
当多次查询发现est_minutes不降反升，说明后台估算在根据实时负载修正，未必是故障，但若伴随v$asm_disk的ERROR，就必须暂停操作并联系存储管理员。借助v$asm_operation提供的量化指标，变更从盲目等待变成可观测任务，显著降低RAC存储调整的风险。
总结来说，v$asm_operation不是孤立的数字表，而是连接ASM调度、磁盘状态与业务IO的观测台。养成在每次磁盘组变动时记录其输出、对比历史速率的习惯，能让集群运维从救火转向预防。
Oracle_RACASMv$asm_operation修改时间：2026-08-16 07:12:15