在Oracle RAC环境中，ASM磁盘组扩容是解决存储容量瓶颈的核心手段，而新增的物理磁盘必须先被识别为候选磁盘，才能被磁盘组接纳。这个环节并不只是执行一条ADD DISK语句那么简单，它同时涉及存储LUN映射、操作系统设备扫描、多路径配置、设备权限设置以及ASM实例的磁盘发现机制。任何一个环节出了问题，最终面对的都是ORA-15032或ORA-15075这类让人头疼的错误。
一、候选磁盘在ASM体系中的角色
ASM磁盘组中的每个磁盘，其头部都保存着一段特殊的元数据，用来记录该磁盘属于哪个磁盘组、成员编号以及盘头状态等信息。当一个磁盘还没有被任何磁盘组接纳时，它就处于候选磁盘状态，在ASM的术语中称为Candidate Disk。ASM实例执行添加操作时，会向候选磁盘写入新的磁盘头，把它升级为磁盘组成员。
磁盘头的状态值直接决定了磁盘能不能被磁盘组使用。常见的状态有CANDIDATE、PROVISIONED、MEMBER和FORMER四种。CANDIDATE表示磁盘完全未被使用，是ASM最期待的添加对象。PROVISIONED表示磁盘已经被Oracle ASM工具初始化过，但尚未加入任何磁盘组，同样可以添加。MEMBER表示磁盘已经归属某个磁盘组，不能重复添加。FORMER表示磁盘曾经属于某个磁盘组但被移除了，这类磁盘在添加时会触发更严格的检查。
| 磁盘头状态 | 含义 | 是否可以添加 |
|---|---|---|
| CANDIDATE | 未被ASM使用过的裸磁盘 | 可以 |
| PROVISIONED | 已被ASM工具初始化，未加入磁盘组 | 可以 |
| MEMBER | 已经是某个磁盘组的成员 | 不可以 |
| FORMER | 曾属于某个磁盘组，后被移除 | 可以，但需谨慎 |
在RAC环境下，所有节点必须能通过相同的设备路径看到同一块候选磁盘。如果节点A能看到而节点B看不到，ASM实例之间就无法达成一致性，磁盘组配置操作会直接失败。理解这一点，就能明白为什么添加候选磁盘时，首先要检查每个节点的设备可见性、权限和ASM_DISKSTRING参数。
二、添加候选磁盘前的底层准备
存储工程师在存储阵列上划分好LUN并映射给数据库节点后，操作系统层面需要先完成扫描。Linux环境中使用multipath -ll命令查看多路径设备是否已正常生成，同时确认/dev/mapper下出现了对应的设备文件。多路径配置的核心是保证每个LUN在操作系统里只有一个稳定的设备入口，如果重复路径没有合并，ASM会同时看到多个表示同一物理磁盘的设备名，最终报错ORA-15075。
设备文件生成后，必须把属主和权限调整为grid用户可读写。RAC环境普遍采用UDEV规则管理ASM磁盘设备，在/etc/udev/rules.d目录下新增规则文件，指定设备的OWNER为grid、GROUP为asmadmin、MODE为0660。下面是一段典型的UDEV规则示例，注意RESULT值需要与存储LUN的SCSI标识完全一致：
KERNEL=="sd?*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$parent", RESULT=="3600508b1001c123456789abcdef", NAME="asm-disk07", OWNER="grid", GROUP="asmadmin", MODE="0660"
规则编写完成后，执行udevadm trigger让规则生效，再用ls -l /dev/asm-disk07确认权限。这里还容易忽略一个问题：RAC所有节点的设备名称必须保持一致。比如节点1上新增设备叫/dev/asm-disk07，节点2上扫描到的同名设备必须对应同一个LUN。如果两个节点设备名错位，ASM磁盘发现时就会把不同LUN识别成同一块盘，磁盘组元数据会被严重破坏。若使用Windows环境做ASM测试，同样要确认磁盘管理器中每个磁盘的SCSI地址，以及C:\Windows\System32\drivers\etc\hosts文件中的节点映射关系是否存在异常。
三、正式添加候选磁盘的操作流程
底层准备结束后，先切换到grid用户，通过kfod工具确认ASM实例能否识别新增设备。kfod是Oracle自带的磁盘发现工具，它会读取ASM的磁盘发现参数，输出当前可见的候选磁盘和磁盘组信息。执行kfod disks=true命令，如果列表里出现了新增设备路径，说明ASM实例已经能看到这块盘。
接下来用asmcmd lsdsk -p查看当前磁盘组内的磁盘信息，确认新增设备没有和现有磁盘组重名。一切正常后，执行以下的ALTER DISKGROUP语句来添加候选磁盘：
ALTER DISKGROUP DATA ADD DISK '/dev/asm-disk07' NAME data07;
这条语句的执行过程涉及磁盘头初始化、磁盘组成员元数据更新以及后续的REBALANCE数据重平衡。如果磁盘组本身设置了较高的冗余级别，新磁盘加入后会自动启动重新平衡任务，把原有数据分布到新磁盘上。
如果希望以图形化方式操作，也可以运行asmca工具，在Disk Groups页面选择对应磁盘组，点击Add Disks按钮，勾选候选磁盘后提交。图形化工具本质上执行的还是ADD DISK操作，但它在磁盘状态检查上更直观，适合初学阶段使用。
操作完成后，需要验证磁盘是否真正成为磁盘组成员。执行下面的SQL查询：
SET LINESIZE 200 COL PATH FORMAT A30 SELECT GROUP_NUMBER, DISK_NUMBER, NAME, PATH, STATE, HEADER_STATUS FROM V$ASM_DISK ORDER BY GROUP_NUMBER, DISK_NUMBER;
查询结果中，新磁盘的GROUP_NUMBER应该等于目标磁盘组编号，STATE为NORMAL，HEADER_STATUS为MEMBER。只要这三项都正确，就说明候选磁盘已经成功转正。
四、添加过程中的常见坑点与排错思路
不少DBA在添加时遇到ORA-15032 ADD DISK操作失败，紧接着的ORA-15075提示设备不是ASM磁盘或无法被发现。这类错误最容易出现在刚映射新LUN的场景里。首先要检查ASM实例的ASM_DISKSTRING参数，它定义了ASM审视设备路径的范围。如果参数值限制了设备目录，新增设备路径不在其中，ASM实例自然不会识别它。使用SHOW PARAMETER ASM_DISKSTRING查看当前值，必要时用ALTER SYSTEM修改并重启ASM实例。
另一个高频坑点在于REBALANCE对数据库性能的影响。添加候选磁盘触发REBALANCE时，如果磁盘组数据量大，重平衡过程会持续很长时间。可以在ADD DISK语句中附加POWER子句临时限制重平衡速度，例如ALTER DISKGROUP DATA ADD DISK '/dev/asm-disk07' REBALANCE POWER 1。性能敏感的业务高峰期，尽量选择低POWER值，等重平衡结束后再通过V$ASM_OPERATION视图确认操作是否完成：
SELECT OPERATION, STATE, POWER, SOFAR, EST_WORK FROM V$ASM_OPERATION;
当EST_WORK和SOFAR相等时，重平衡任务完成。如果测试环境在Windows上，需要注意Windows的ASM不支持RAC，只支持单实例，排错思路虽然一致，但路径规则不同。Windows下ASM的ADR日志目录通常位于C:\Oracle\diag\asm\asm_+ASM\trace，Linux环境则默认在/u01/app/grid/diag/asm/+ASM/trace。查看对应的alert日志，几乎能定位所有磁盘添加失败的第一现场。
最后要提醒的是，FORMER状态的磁盘在重新添加时，需要确认它原来所属的磁盘组是否还存在。如果原磁盘组已经被删除，FORMER磁盘可以安全添加；如果原磁盘组还存在，贸然添加会让ASM误认为磁盘要回归旧组。稳妥的做法是先用dd命令清除磁盘头部前100MB数据，再重新扫描设备，让磁盘回到CANDIDATE状态。