Rebalance卡在WAITING或EXECUTING且EST_MINUTES不更新，首要排查底层磁盘健康：检查smartctl中Reallocated_Sector_Ct等三项、/var/log/messages的I/O错误及dd写入延迟；确认是否坏道盘处于DROPPING状态但迁移阻塞；排除CSSD心跳抖动导致的“假死”；换盘后须校验WWN一致性并执行CHECK ALL。
Rebalance卡在WAITING或EXECUTING但EST_MINUTES不更新，先查底层磁盘健康
这不是asm配置问题，而是存储层在“装死”——rebalance挂起最常见的硬件诱因是磁盘存在坏道、smart预警未触发离线、或hba卡/光纤链路存在间歇性crc错误。这些情况不会让磁盘直接掉线（所以v$asm_disk状态仍是online），但会导致asm读写超时后反复重试，最终阻塞au迁移流程。
实操建议：
- 在所有RAC节点上分别执行
smartctl -a /dev/sdX（替换为实际设备名），重点关注Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count三项；值非零即高风险 - 检查
/var/log/messages中是否有end_request: I/O error、aborted command或resetting link等关键词，时间戳需与Rebalance启动时间对齐 - 运行
dd if=/dev/zero of=/dev/sdX bs=1M count=1024 oflag=direct测试写入延迟，若单次耗时>500ms或报Input/output error，基本可锁定该盘 - 不要依赖
asmcmd lsdsk的“可见性”判断——它只校验路径可达，不校验扇区可写
确认坏道盘是否已被ASM标记为DROPPING但无法完成迁移
当底层磁盘响应异常但未彻底失联时，ASM会将其置为DROPPING状态并尝试迁移其上的AU，但因读取失败而卡住。此时v$asm_operation可能显示STATE = 'EXECUTING'，但v$asm_disk中该盘的HEADER_STATUS可能是PROVISIONED或UNKNOWN，而非MEMBER。
实操建议：
- 执行
SELECT name, state, header_status, mode_status, repair_timer FROM v$asm_disk WHERE group_number = (SELECT group_number FROM v$asm_diskgroup WHERE name = 'YOUR_DG_NAME'); - 若目标磁盘
state = 'DROPPING'且repair_timer = 0，说明ASM已放弃等待，但AU迁移逻辑被I/O错误阻塞 - 此时
ALTER DISKGROUP ... DROP DISK已无效，必须先用FORCE强制清除元数据残留：ALTER DISKGROUP YOUR_DG_NAME DROP DISK 'ORCL:BAD_DISK' FORCE; - FORCE操作后，需手动触发
REBALANCE，否则磁盘组冗余度持续受损
避免误判：别把CSSD心跳抖动当成Rebalance卡死
RAC环境下，Rebalance长时间无进展，常被误认为是ASM问题，实际根源可能是集群同步服务（CSSD）心跳不稳。当光纤链路或私网交换机出现微秒级丢包时，CSSD会频繁重传，导致v$css_history中出现大量missed checkin记录——这会让ASM实例进入保护模式，主动降低IO并发，表现为Rebalance“假死”。
实操建议：
- 立即检查
v$css_history：SELECT event, time, node_name FROM v$css_history WHERE time > SYSDATE-1/24 ORDER BY time DESC;，重点抓missed checkin和node eviction - 对比
v$asm_client中各节点状态：若某节点status为INTERMEDIATE或FAILED，说明该节点ASM实例虽存活，但已失去集群视图一致性 - 此时强行调高
REBALANCE POWER只会加剧I/O争抢，应优先修复网络层——检查私网MTU是否一致、交换机buffer是否溢出、网卡驱动是否过旧
坏道盘替换后，必须验证ASM元数据与物理盘的一致性
换新盘后，仅执行ADD DISK和REBALANCE不够。ASM不会自动校验新盘是否真正覆盖了旧盘的LUN ID或WWN，尤其在SAN环境中，若存储侧未刷新映射关系，ASM可能将新盘识别为“重复路径”，导致后续操作报ORA-15075或ORA-15137。
实操建议：
- 新加盘前，在OS层确认
scsi_id -g -u -s /block/sdX输出的WWN与旧盘完全不同，且未出现在ls -l /dev/disk/by-id/的旧别名中 - 添加后立即查
gv$asm_disk：SELECT inst_id, name, path, failgroup FROM gv$asm_disk WHERE path LIKE '%sdX%';，确保所有节点看到的path和failgroup一致 - 切勿跳过
ALTER DISKGROUP ... CHECK ALL——它会扫描每个AU的校验和并比对镜像副本，发现坏块会自动标记为CORRUPT，这是唯一能确认数据完整性的手段
v$asm_operation还在跑，就以为一切正常，其实后台IO早已在反复重试中耗尽资源。务必把smartctl和/var/log/messages当成第一诊断入口，而不是一上来就调POWER参数。 
