能平滑迁移，但“在线”不等于“无感知”：rebalance期间i/o压力和sql响应延迟明显上升，normal冗余磁盘组删盘时若剩余磁盘数不足会导致操作失败。
能平滑迁移，但“在线”不等于“无感知”——rebalance期间i/o压力和sql响应延迟会明显上升，且normal冗余磁盘组删盘时若剩余磁盘数 ora-59048 会直接中断操作。
为什么alter diskgroup ... drop disk会报ORA-59048
Oracle 19c中Normal冗余磁盘组要求至少3块有效磁盘维持镜像一致性。执行drop disk前，必须确认删除后磁盘组内仍保留≥3块HEADER_STATUS = 'MEMBER'的磁盘。否则ASM拒绝操作，并抛出ORA-59048: insufficient number of disks in diskgroup。
常见误判点：
- 未过滤
v$asm_disk中状态为MISSING或FORMER的磁盘（它们不计入有效磁盘数） - 误将同一failgroup下的多块盘同时删除（Normal冗余要求每个failgroup至少1块存活）
- 未检查
gv$asm_operation是否已彻底结束——残留的rebalance任务会导致后续drop被阻塞
rebalance power值设多少才合理
rebalance power控制重平衡并行度，默认为1，最大支持11（19c）。值越大，同步越快，但磁盘I/O和CPU争用越剧烈，业务SQL延迟可能翻倍。
生产环境建议按场景选值：
- 低峰期大容量迁移（如TB级）：用
power 7–9，配合select * from gv$asm_operation监控EST_MINUTES下降趋势 - 业务高峰期小范围替换（如单块盘）：严格限制为
power 1–3，避免触发DBWR写入瓶颈 - OCR/VOTING磁盘组：一律用
power 1，防止集群心跳抖动
注意：power不可动态下调，一旦设高，只能等当前rebalance完成再发起新命令。
Drop磁盘后v$asm_disk里还显示MISSING怎么办
这是典型的状态残留——磁盘已从ASM逻辑移除，但OS设备路径失效或权限异常，导致ASM无法清理其元数据记录。
验证与处理步骤：
- 先确认OS层设备是否存在：
ls -l /dev/mapper/xxx或blkid | grep xxx - 若设备已消失，但
v$asm_disk.path仍指向旧路径，说明磁盘头未清除；此时不能直接kfed repair，需先alter diskgroup ... dismount - 真正安全的做法是：在所有节点确认该磁盘无任何IO后，用
dd if=/dev/zero of=/dev/mapper/xxx bs=1024 count=100擦除前100KB（覆盖disk header），再重启ASM实例 - 切忌在
MISSING状态下对同一磁盘组执行add disk——可能引发ORA-15032和磁盘组挂起
最易被忽略的一点：迁移前后务必比对v$asm_diskgroup.total_mb与v$asm_disk.sum(total_mb)是否一致。差值不为0，说明有磁盘未被ASM识别或存在隐藏的CANDIDATE盘，后续加盘或删盘都可能失败。
