手头正好接到一个存储替换的活：老的存储阵列要下电退役，上面挂的ASM磁盘组全是Oracle数据文件，业务还不能长时间停。按照常规思路，要么用expdp导出导入，要么用存储层的LUN复制做冷迁移，但前者时间窗口根本不够，后者又牵扯到卷映射变更和中间状态校验。最后我选了ASM最经典的玩法——通过rebalance把磁盘数据从旧盘“平滑”到新盘上，整个过程对数据库层面完全透明，数据文件路径、ASM别名一概不用改。
这篇文章就围绕这套操作展开，适合正在做存储替换、磁盘扩容、或者单纯想把ASM磁盘组从一组物理盘挪到另一组物理盘的朋友参考。文章会讲rebalance的底层原理、操作步骤、参数怎么定，以及我实际踩过的坑。
1. 为什么选rebalance做磁盘迁移
1.1 磁盘迁移的几种方案对比
遇到磁盘迁移需求，很多DBA脑子里第一反应是数据泵导出导入。逻辑迁移确实能跨平台、跨版本，甚至能把数据从Oracle搬到其他数据库，但在这类“存储替换”场景里它并不是最优解。数据泵要经过逻辑解析和SQL重放，全库导出导入的时间通常是物理迁移的3到5倍，而且源库端的业务对象、序列、物化视图、同义词等元数据多多少少都有重建成本，稍不注意就漏掉对象。
第二种方案是干脆停库，把数据文件直接拷贝到新磁盘上，再改ASM磁盘组或者用文件系统管理。这种方式逻辑上最简单，但问题在于停机窗口。现在业务部门给DBA的窗口经常只有两三个小时，几百GB的小库还好说，碰上几个TB的大库，裸拷贝的时间根本不够。而且一旦文件拷贝过程中出现中断，整个一致性就泡汤了，恢复起来非常痛苦。
所以在这类场景下，ASM的rebalance就显出价值了。它属于在线物理级的数据重分布，不需要停库，不需要改数据库端的任何配置。你只需要向磁盘组里增加新磁盘，再删除旧磁盘，ASM会在后台自动把数据块从旧盘搬移到新盘。数据库完全感知不到存储路径的变化，所有数据文件、控制文件、日志文件的ASM别名保持原样，这对业务连续性来说是最友好的。
1.2 先确认存储架构和冗余策略
动rebalance之前，第一件事不是敲命令，而是先摸清磁盘组的冗余架构。ASM磁盘组有三种冗余类型：EXTERNAL（外部冗余，通常由存储阵列做RAID）、NORMAL（两副本）、HIGH（三副本）。冗余类型直接决定了迁移过程中的风险和空间要求。
如果磁盘组是EXTERNAL冗余，意味着ASM本身没有做镜像，一块盘损坏，数据就丢。这种架构下做rebalance迁移，新盘加进来之后数据会从旧盘拷贝到新盘，这个过程中旧盘如果出现故障，数据是不可恢复的。所以我通常会建议：EXTERNAL冗余的磁盘组，在执行迁移前一定要做一次全量备份，最好是image copy级别的备份，或者确保存储阵列层面有可靠的快照。
对于NORMAL和HIGH冗余的磁盘组，情况会好很多。ASM天然会在不同failgroup里保留副本，迁移过程中即使某个旧盘挂了，只要还有一份完整副本在，磁盘组可以继续工作，rebalance也能继续推进。但这里面有个容易忽略的点：很多环境里虽然磁盘组是NORMAL冗余，但所有物理盘都在同一个存储阵列里，所谓failgroup分离并没有体现到硬件级别的容灾上。这种时候我建议把每个物理存储LUN单独划成一个failgroup，这样rebalance在搬数据的时候才会真正把副本打散到不同的物理设备上。
查看磁盘组冗余类型的命令很简单，用grid用户登录ASM实例，执行：
SELECT name, type, total_mb, free_mb, required_mirror_free_mb, usable_file_mb FROM v$asm_diskgroup;type字段直接显示EXTERN、NORMAL或HIGH。需要注意的是required_mirror_free_mb这个字段，它表示ASM为了保证冗余度而必须保留的镜像空间。在后续估算删除旧盘所需空间时，这个值是重要的参考。
2. rebalance到底做了什么
2.1 核心后台进程与工作流
rebalance不是虚无缥缈的“自动平衡”，它背后是一套完整的过程协作机制。ASM实例里有两个关键后台进程：RBAL和ARBx。RBAL是rebalance的协调者，负责监控磁盘组的变化、生成rebalance计划、把任务分解并分发给ARB进程。ARB0到ARBn是实际干活的进程，数量由POWER参数决定，它们负责把extent从源盘读取、再写入目标盘。
从工作流来看，rebalance分两个阶段。第一阶段叫“规划”，RBAL进程根据磁盘组的现有分布、各盘剩余空间、failgroup配置，计算出一份数据移动计划，说白了就是哪些extent需要从哪块盘挪到哪块盘。第二阶段是“执行”，ARB进程按计划逐块搬移，每搬完一个extent就更新一次元数据指针，数据库访问到这部分数据时，会通过ASM的元数据层自动定位到新位置，整个过程对数据库完全透明。
还有一个容易忽略的点是，rebalance不仅发生在你主动执行ADD或DROP磁盘时。如果某块盘发生性能抖动或者读写延迟异常，ASM也可能自动触发轻量级的rebalance来重新打散数据。所以有时候你什么都没做，v$asm_operation里却能看到REBAL操作，就是这个原因。
2.2 POWER参数是怎么影响速度的
ASM rebalance的速度由POWER参数控制。这个参数的作用是控制同时运行的ARB进程数量，取值为0到11，值越大并行度越高，搬移速度越快，但带来的IO压力也越大。
POWER参数有两个层面的设定方式。一个是实例级参数ASM_POWER_LIMIT，可以通过以下命令查看和修改：
SHOW PARAMETER ASM_POWER_LIMIT; ALTER SYSTEM SET ASM_POWER_LIMIT=5 SID='*';另一个是语句级的REBALANCE POWER子句，比如：
ALTER DISKGROUP data ADD DISK '/dev/mapper/data05' REBALANCE POWER 8;语句级的POWER优先级高于实例级参数。也就是说，即使实例级ASM_POWER_LIMIT设的是3，如果在ADD语句里指定了POWER 8，这次rebalance就会按8的并行度执行。
实际项目里我一般的建议是：如果业务处于高峰时段，POWER设在2到3之间，保证rebalance不抢太多IO；如果业务低谷或者停机维护窗口，可以拉到6到8；POWER 10到11是给那种“赶紧搬完，别的都不管”的场景用的，比如整阵列迁移。这里有个误区，很多人觉得POWER越大越好，其实不是。ARB进程越多，对ASM实例的SGA内存和CPU消耗也越大，如果底层存储IO本身就存在瓶颈，POWER开太高反而可能引起数据库性能直线下降，甚至出现IO hang。
2.3 rebalance过程中潜在风险
rebalance虽然在线、透明，但风险点也不少，提前了解才能提前规避。
第一是IO双倍压力。rebalance执行期间，老数据还在对外提供服务，新数据的搬移又在不断读取和写入，整个存储系统的IO压力会明显上升。如果底层存储本身IOPS余量不多，业务端就可能出现延迟飙升，甚至TTL超时。
第二是空间妥协风险。加新盘的空间需求相对可控，真正要注意的是删老盘的阶段。删盘时，ASM会把老盘上的所有extent在其他盘上重建一份，这就要求磁盘组剩余空间至少要大于等于老盘当前已经使用的数据量。空间不够的话，rebalance会一直卡在某个状态，甚至报ORA-15032或ORA-15041错误。
第三是ASM实例重启的风险。rebalance过程中如果ASM实例意外重启，操作一般会在ASM恢复后继续，但复杂环境下可能出现rebalance与挂载、磁盘offline等状态交叉，处理起来会麻烦不少。所以正式执行前，最好先确认ASM实例的稳定性，比如检查alert日志有没有ORA-600、内存问题等隐患。
还有一个容易忽略的地方是磁盘组空间利用率。rebalance时ASM会优先把数据分配到可用空间多的盘上，如果你加进来的新盘和其他旧盘容量差距很大，比如新盘2TB，旧盘全是300GB，新盘加进来后几乎所有数据都会优先往新盘上搬，最终导致新盘很快就满了，其他盘还是很空。这种情况在数据库后续扩容时会造成严重的空间不均，所以条件允许的情况下，尽量让同一组磁盘的容量接近。
3. 实操过程：从准备到切换
3.1 迁移前环境检查
动手之前，先把环境信息摸清楚。我习惯先列一张检查清单，包含以下几个方面：磁盘组冗余类型、各盘容量和路径、ASM实例版本、当前ASM_POWER_LIMIT值、告警日志是否干净、数据库端有无异常任务。
以grid用户登录ASM实例，查看磁盘组和磁盘状态：
SELECT name, group_number, state, type, total_mb, free_mb FROM v$asm_diskgroup; SELECT group_number, disk_number, name, path, failgroup, total_mb, free_mb, state, mode_status, mount_status FROM v$asm_disk ORDER BY group_number, disk_number;这里重点看三列：state是否都是NORMAL，mode_status是否都是ONLINE，mount_status是否都是CACHED。如果发现某块盘是OFFLINE或者UNKNOWN，先不要动其他盘，先处理这块盘的异常，否则rebalance执行到一半可能出现不可预料的后果。
再看一眼asm_diskstring参数，确保新盘的路径能被ASM自动扫描到：
SHOW PARAMETER ASM_DISKSTRING;如果磁盘是通过udev规则映射到/dev/mapper/下的，通常设为/dev/mapper/asm-*这种通配符形式。如果ASM使用的是ASMLib，则对应ORACLEASM_DISKSTRING。
新盘接入操作系统的步骤这里简单说一下。存储端划分好LUN并映射给主机后，在操作系统层面通过multipath -ll确认多路径设备已经识别，例如新盘对应/dev/mapper/asm-data05。然后需要给磁盘打上持久化标签，并在udev规则里绑定好权限，确保grid用户能够读写这个设备。我见过不少新盘加入后ASM识别不到的情况，绝大多数都是因为udev规则没生效或者权限不对，所以这一步一定不要偷懒。配置完udev规则后，记得执行udevadm control --reload还有udevadm trigger让规则生效，然后再去ASM实例里扫描。
扫描新盘进ASM，可以在SQLPLUS里执行：
ALTER SYSTEM DISK SCAN ALL;或者用asmcmd的命令：
asmcmd scandisks扫描完之后，再次检查v$asm_disk视图，确认新盘已经以candidate状态出现，并且header_status不是FORMER或者FOREIGN。
3.2 执行rebalance迁移
环境确认没问题，就可以正式开始迁移了。我的习惯是先把新盘全部加到磁盘组，等待rebalance完成，再做旧盘的删除，而不是新旧盘交替进行。这样做的好处是，ADD阶段磁盘组空间只会增加不会减少，即使旧盘在过程中出问题，风险也相对可控。
把新盘加入DATA磁盘组，示例命令如下：
ALTER DISKGROUP data ADD DISK '/dev/mapper/asm-data05' NAME data_005 REBALANCE POWER 5; ALTER DISKGROUP data ADD DISK '/dev/mapper/asm-data06' NAME data_006 REBALANCE POWER 5; ALTER DISKGROUP data ADD DISK '/dev/mapper/asm-data07' NAME data_007 REBALANCE POWER 5;注意每块盘都显式指定了NAME，这是为了避免ASM自动生成一串难以识别的磁盘别名，后续在DROP的时候直接按名字操作，不容易弄错。
ADD操作提交后，rebalance立刻开始。查看进度：
SELECT group_number, operation, state, power, sofar, est_work, est_minutes FROM v$asm_operation;字段含义：sofar表示已经完成的rebalance工作量，est_work是预估总工作量，est_minutes是预估剩余分钟数。当state显示为COMPACT时，说明正在做压缩和整理，这是rebalance收尾阶段的正常现象，不需要干预。
等rebalance全部完成，再执行旧盘删除：
ALTER DISKGROUP data DROP DISK data_001 REBALANCE POWER 5; ALTER DISKGROUP data DROP DISK data_002 REBALANCE POWER 5; ALTER DISKGROUP data DROP DISK data_003 REBALANCE POWER 5;如果担心同时删除多块盘导致空间压力太大，可以一次删除一块，等rebalance完成后再删下一块。不过一次删一块的弊端是总迁移时间会线性拉长，且每一次rebalance都是全量重分布，效率反而低。我在实际生产环境里，只要空间估算确认过，一般会一次性把同一批旧盘都DROP掉，让ASM统一调度。
删除完成后再次检查磁盘组和磁盘状态，确认旧盘已经从v$asm_disk中消失，磁盘组所有盘都已ONLINE，且各盘的FREE_MB相对均匀。
3.3 迁移过程业务影响控制
rebalance最怕的不是慢，而是对业务产生不可接受的性能冲击。我的经验是分三层来控制。
第一层是POWER值。默认情况下，如果不在语句里显式指定POWER，就会用实例级ASM_POWER_LIMIT。为了保证每次rebalance都能按预期速度执行，我会在ADD和DROP语句里都显式带上REBALANCE POWER参数。
第二层是执行时机。即便用了POWER 5，在业务高峰时段执行大规模rebalance仍然可能导致存储IOPS被打满。所以我会提前和业务方确认低峰窗口，一般是凌晨两三点，把ADD和DROP操作都安排在这个窗口内执行。
第三层是实时监控。rebalance执行期间，我一般每隔五到十分钟查一次v$asm_operation和存储端的性能监控，看到磁盘utilization持续超过85%或者数据库等待事件出现明显异常，就把power调低一档。POWER是可以动态调整的，不用取消rebalance，直接改实例级参数配合语句级命令：
ALTER DISKGROUP data REBALANCE POWER 3;这条命令可以在不中断rebalance的前提下，把当前及后续阶段的并行度调低。
3.4 验证与切换
rebalance完成后不能拍拍屁股就走，要做一轮完整验证。
第一步，确认v$asm_operation里没有任何正在执行的REBAL操作记录。
第二步，检查磁盘组整体状态：
SELECT name, state, total_mb, free_mb, usable_file_mb FROM v$asm_diskgroup;第三步，确认数据库端无感知。登录数据库实例，执行：
SELECT name, file#, status FROM v$datafile; SELECT name, status FROM v$controlfile; SELECT group#, status, type FROM v$log;这些都显示正常，说明数据库的数据文件和控制文件访问都没有问题。
第四步，确认ASM告警日志里没有异常错误。告警日志位置可以通过：
asmcmd alert快速定位。
确认无误后，就可以在操作系统层面把旧盘从存储映射中解绑，删除对应的udev规则，清理multipath配置。这一步我也吃过亏，旧盘如果还残留在操作系统上，下次ASM扫描磁盘时有可能把它当作candidate盘扫进来，一旦误加到某个磁盘组，后果非常严重。
4. 常见问题与排查实录
4.1 rebalance进度一直卡着不动
rebalance最让人焦虑的现象就是进度条不走。v$asm_operation里sofar一直没有增长，est_minutes还在不停变大，或者干脆报错退出。
遇到这种情况，第一步看磁盘组的空间。用：
SELECT name, total_mb, free_mb, required_mirror_free_mb FROM v$asm_diskgroup;对比需要删除的旧盘容量，如果free_mb减去required_mirror_free_mb后的可用空间小于旧盘当前数据量，rebalance就极容易卡住。解决办法是再加一块新盘进来扩容，或者降低删除磁盘的规模。
第二步看磁盘状态。如果某块旧盘处于OFFLINE状态，而它上面还有extent没有搬完，rebalance就会一直等待。用：
SELECT name, state, mode_status, mount_status FROM v$asm_disk;发现有OFFLINE的盘，先执行：
ALTER DISKGROUP data ONLINE DISK data_00N;把盘恢复在线，再观察rebalance是否继续。
第三步看alert日志。ASM的alert日志会记录rebalance暂停或失败的具体原因，比如ORA-15041（磁盘空间不足）或者ORA-15085（磁盘组已满）。
4.2 新盘加入后状态UNKNOWN或无法识别
新盘加入磁盘组后，v$asm_disk里显示UNKNOWN，或者扫描后根本看不到新盘，这类问题大多出在操作系统层。
最常见的是权限问题。ASM进程要以grid用户身份读写磁盘设备，如果udev规则没有给对权限，磁盘就只能看到设备节点而打不开。检查/dev/mapper/asm-data05的属主和权限，确认owner是grid，group是asmadmin，mode是660。
另一个是路径识别问题。ASM_DISKSTRING设置的是/dev/mapper/asm-*，而新盘在multipath里生成的设备名不在这个通配符范围内，扫描就看不到。解决办法是把新盘的别名规范好，统一命名。
还有一种情况是磁盘头已经被其他系统写入了文件系统或分区信息，导致ASM无法识别这是ASM盘，状态会变成FOREIGN。新盘如果是旧设备重新利用的，最好在操作系统层用dd把磁盘头清掉：
dd if=/dev/zero of=/dev/mapper/asm-data05 bs=1M count=100然后再重新扫描。
4.3 rebalance误删盘后如何救回
生产环境里手滑是难免的，ADD盘的时候加错了盘，或者DROP盘的时候名字写错，都可能导致误操作。
如果只是误把一块新盘DROP了，rebalance尚未完成，还有救。ASM提供了UNDROP命令：
ALTER DISKGROUP data UNDROP DISKS;这个命令可以恢复最后一次DROP操作中被移除的磁盘，只要rebalance还没最终完成，数据extent可能还没有完全清除，就有机会恢复。但如果rebalance已经执行完毕，UNDROP就无效了，此时只能重新ADD磁盘。
还有一种情况是ADD盘加错了路径，把操作系统上正在使用的盘误加进了ASM磁盘组。这种操作风险很高，ASM会尝试格式化该盘并写入ASM磁盘头，如果盘上有正在使用的文件系统，数据基本就废了。遇到这种情况，第一时间要把错误磁盘从ASM中DROP掉，并立即通知存储和系统团队评估数据恢复方案。这再次说明，提前核实路径和磁盘头状态有多么重要。
4.4 OCR和VOTE磁盘组的特殊处理
ACFS、OCR和VOTE磁盘组也是ASM磁盘组，很多人会想当然地用同样的ADD和DROP方式去迁移。但这里要特别提醒，OCR和VOTE磁盘组承载的是Clusterware的核心文件，路径一旦发生变化，CRS可能起不来，整个集群都会受影响。
对于OCR磁盘组，推荐使用ocrconfig工具来管理替换，具体命令是：
ocrconfig -add +新磁盘组 ocrconfig -delete +旧磁盘组VOTE磁盘组则使用votedisk命令或crsctl命令进行操作：
crsctl replace votedisk +新磁盘组这类操作虽然底层也会触发ASM rebalance，但流程完全不同，建议由有经验的集群管理员来处理。文章前面讲到的ADD/DROP方式，主要适用于普通数据磁盘组。
5. 事后清理与复盘
5.1 清理操作系统层旧盘配置
迁移完成后，旧盘虽然离开了磁盘组，但操作系统层的配置还留着。如果不清理干净，有两个隐患：一是后续ASM扫描时可能把旧盘误识别为candidate盘；二是容易让人搞混当前环境里到底有哪些盘在用。
清理内容包括：删除udev规则中对应的旧盘条目，移除multipath配置中对应的磁盘映射，从存储端解除LUN映射，如果设备节点还残留在系统里，用multipath -l确认没有活动路径后移除。做完这些之后，再执行一次ASM磁盘扫描，确认旧盘没有出现在candidate列表里。
5.2 复盘文档与后续优化建议
一次rebalance迁移做完，我建议写一篇复盘文档，核心记录三块内容：迁移前后的磁盘组布局对比、rebalance各阶段的实际耗时和POWER配置、期间出现的异常和处理方式。这些数据对后续类似操作非常有参考价值。
如果迁移后磁盘组空间充裕，还可以考虑调整数据库的ASM相关参数，比如DB_FILES、CONTROL_FILES等，但这些属于可选项，不影响正常业务。
最后想分享一个经验，就是迁移后不要马上把旧存储断掉，至少保留一两天时间观察数据库运行状态，确认所有文件访问都正常后再执行下线操作。我碰到过几次，迁移当天一切正常，但第二天有归档日志或备份任务触碰到旧盘路径，才发现还有遗漏的依赖关系。这种问题在保留期内发现和处理都还来得及，一旦旧存储彻底断电，麻烦就大了。
