在Oracle RAC集群的长期运行中，ASM磁盘所在的光纤盘阵、本地SSD或iSCSI存储总会遇到磁盘老化、容量不足需要换更大盘、存储设备整体迁移等情况。ASM磁盘更换并不是简单地拔旧插新，它涉及磁盘组冗余策略、数据重平衡以及多节点磁盘识别一致性的问题。如果操作顺序不对，轻则rebalance任务失败，重则磁盘组被强制下线，整个数据库实例随之崩溃。本文按照一次标准的存储迁移场景，把更换ASM磁盘的完整流程和注意事项梳理清楚。
更换前的检查与准备工作
动手之前必须先摸清磁盘组的现状。登录ASM实例（通常是+ASM1或+ASM2），确认磁盘组的冗余类型、当前磁盘列表以及每块盘的使用率。冗余类型决定了更换过程中的风险等级：EXTERNAL冗余意味着ASM不提供镜像，一块盘的损坏或误删除会直接导致数据丢失，更换时更要确认rebalance彻底完成后才能下线旧盘；NORMAL冗余至少有两份副本，操作容错空间相对大一些。
可以用下面的语句查看磁盘组信息，重点关注PATH、HEADER_STATUS和MODE_STATUS这几个字段。HEADER_STATUS为MEMBER表示磁盘正常属于某个磁盘组，如果出现FORMER说明这块盘曾经属于磁盘组但已被移除，CANDIDATE则表示可以被加入：
-- 查看磁盘组及成员盘状态 set linesize 200 col path for a40 col name for a20 select group_number, name, type, total_mb, free_mb from v$asm_diskgroup; select disk_number, name, path, header_status, mode_status, total_mb, free_mb from v$asm_disk where group_number = 1 order by disk_number;
除了ASM层面，还要确认新磁盘在所有RAC节点上都能被正确识别，且设备名一致。这一步非常关键，RAC是多节点共享存储的架构，如果节点A看到的新盘是sdb，节点B上却是sdc，而磁盘组创建时用的路径字符串不匹配，就会导致节点加入磁盘组失败。建议配合udev规则或多路径（multipath）固定设备名，保证每个节点访问同一块物理磁盘时使用相同的路径。同时检查磁盘头是否有旧数据残留，必要时用dd清空磁盘头前几个扇区，避免出现HEADER_STATUS为MEMBER但实际不属于任何组的脏盘。
添加新盘并触发rebalance的核心操作
更换磁盘的标准做法是先加后删：先把新盘加入磁盘组，等ASM自动把数据重新分布到新盘上，确认旧盘上的数据全部迁走之后再删除旧盘。这样整个过程中数据库可以持续在线运行，业务几乎无感知。添加磁盘的语法很简单，但power参数的选择有讲究：
-- 以grid用户登录sqlplus进入ASM实例
-- 添加新盘并指定平衡强度
alter diskgroup DATA add disk
'/dev/asm-disk-new01'
name DATA_NEW01
rebalance power 8;
-- 查看重平衡进度
select group_number, operation, state, actual, sofar, est_work,
est_minutes
from v$asm_operation;
power的取值范围是0到11（11g以及以上版本在Diskgroup Compatible设置允许时可到1024）。power越大，rebalance的并行度越高，数据搬迁越快，但对I/O带宽的占用也越猛，会直接影响在线业务的响应时间。生产环境建议在业务低峰期操作，先用中等power（比如4到6）观察I/O压力，再视情况调整。如果发现业务受影响明显，可以用alter diskgroup DATA rebalance power 2;在线降低强度，不需要取消任务。
v$asm_operation视图中的SOFAR表示已完成的数据区间数，EST_WORK是预估总量，两者相除就是进度百分比，EST_MINUTES给出预计剩余时间。需要注意的是，当rebalance真正跑完，这个视图里对应记录会消失，查询返回空结果，切不可把空结果当成报错。稳妥的做法是配合告警日志确认出现rebalance完成的相关条目，再进入下一步。
删除旧盘、确认数据迁移与收尾清理
确认rebalance完成且无错误后，旧盘上的数据已经全部落到新盘上，此时可以安全地删除旧盘。删除动作同样会触发一次小规模rebalance，把剩余数据在存留的磁盘间再均匀分布一次：
-- 从磁盘组中删除旧盘 alter diskgroup DATA drop disk DATA_OLD01 rebalance power 8; -- 再次确认平衡完成，检查旧盘状态 select disk_number, name, path, header_status, mode_status from v$asm_disk where group_number = 1; -- 如果删除命令已发出但想撤销（仅限数据未迁完时） alter diskgroup DATA undrop disks;
删除后旧盘的HEADER_STATUS会变为FORMER，此时它已经不再属于任何磁盘组，可以从存储层面安全移除。这里有一个容易踩的坑：drop命令发出后如果反悔，只要旧盘数据还没有被完全搬空，undrop disks可以撤销删除；但如果rebalance已经完成、盘已物理移除，就无法挽回了。所以在敲下drop之前，务必再次核对磁盘名称，用v$asm_disk里的NAME和PATH双重确认，避免删错盘。
最后是系统层面的收尾。旧盘物理拔除后，检查udev规则文件（例如/etc/udev/rules.d/目录下的规则）或multipath配置，把旧磁盘对应的WWID条目清理掉，新磁盘的条目要确保在所有节点都已生效。如果是在Windows环境的Oracle RAC上操作，还要注意清理磁盘签名相关配置，例如通过注册表路径HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OracleASM相关的磁盘绑定参数，以及确认C:\Program Files\Grid Infrastructure目录下的配置文件中磁盘路径字符串与实际设备一致。全部节点确认无误后，做一次滚动重启ASM实例或使用crsctl检查集群资源状态，验证集群层面所有资源均为ONLINE，更换工作才算彻底完成。
常见风险与规避方法
第一个大坑是EXTERN冗余磁盘组上删除过快。外部冗余下ASM不做镜像，如果在rebalance尚未完成时强制删除旧盘或直接拔盘，该盘上还未迁移的extent将直接丢失，可能导致文件损坏甚至数据库无法打开。规避方法很简单：每一步操作后都等待v$asm_operation清空，并且删除前用查询确认旧盘FREE_MB接近其TOTAL_MB，即盘上已基本没有数据。
第二个常见问题是磁盘头冲突。新盘如果曾用于其他集群或测试环境，磁盘头残留的ASM元数据会让它被识别为MEMBER却无法加入目标磁盘组，报ORA-15032、ORA-15040之类的错误。处理办法是在加入磁盘组前清理磁盘头，Linux下可用dd if=/dev/zero of=/dev/asm-disk-new01 bs=1M count=100抹掉头部信息，操作前反复确认设备名指向正确的盘。第三个风险是节点间磁盘可见性不一致，务必用ls -l /dev/asm-disk*或clusterware的磁盘检测工具在每个节点核对，必要时通过kfod工具验证各节点识别到的磁盘列表完全一致后再执行ASM层面的变更。
Oracle RACASM磁盘更换磁盘组管理修改时间：2026-09-12 17:08:44