Oracle RAC如何添加ASM磁盘？在线扩容磁盘组而不中断

Oracle RAC在线添加ASM磁盘前的三大关键检查

在Oracle RAC环境中为ASM磁盘组在线扩容，并非执行一条ADD DISK命令即可生效。其成功与否，取决于底层存储设备在多节点间的可见性、ASM实例的识别能力以及磁盘组冗余策略三者的协同。若忽视前置检查，直接运行alter diskgroup ... add disk指令，极有可能遭遇操作长时间挂起于disk_repair_time，或直接触发ORA-15032、ORA-15027等错误代码。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

• 确保新增磁盘在所有RAC节点的操作系统层可见且权限一致：通过ls -l /dev/oracleasm/disks/（若使用ASMLib）或ls -l /dev/mapper/xxx（若使用UDEV）命令进行核查。核心要点在于，磁盘的设备主次号（major/minor）、所属用户与组（应为grid:asmadmin）以及访问权限（通常为brw-rw----）必须在集群的每一个节点上保持完全一致。
• 确认ASM实例已识别到该磁盘路径：分别登录每个节点的ASM实例（sqlplus / as sysasm），执行查询SELECT path, header_status FROM v$asm_disk WHERE path LIKE '%NEW_DISK%';。若返回结果为空，表明ASM尚未扫描到此磁盘，此时需先在对应节点运行ALTER SYSTEM SCAN DISKS;命令以刷新磁盘发现。
• 核实目标磁盘组采用EXTERNAL或NORMAL冗余模式：此点尤为关键。若磁盘组配置为HIGH冗余（即三副本），则新增磁盘必须遵循故障组（Failure Group）规则成对添加。否则，ADD DISK命令将被ASM拒绝执行，并返回ORA-15036错误。

在线添加ASM磁盘的标准语法与核心参数详解

添加磁盘的操作本身支持在线执行，不会中断服务，但其触发的数据重平衡（Rebalance）过程将持续消耗I/O与CPU资源，可能影响业务性能。切勿认为“在线”即等同于“无影响”——尤其当磁盘组已承载TB级数据时，若重平衡强度设置不当，极易引发严重的I/O瓶颈与性能抖动。

• 基础命令格式：ALTER DISKGROUP ADD DISK '' NAME ;。请注意：必须与v$asm_disk.path视图中显示的路径字符串完全匹配，包括大小写及可能的转义字符。
• 管理重平衡操作强度：参数REBALANCE POWER默认值为3，适用于多数场景。在业务维护窗口或低峰期，可提升至5或更高以加快进度；而在生产高峰期，则建议显式设置为POWER 1以降低影响，并可附加WAIT选项使命令等待当前阶段完成，避免后台任务堆积。
• 为磁盘显式命名以避免混淆：强烈建议在ADD DISK时使用NAME子句指定一个有意义的磁盘名。若省略，ASM将自动分配DATA_0001之类的通用编号，这在后续的磁盘删除、替换或故障诊断时极易造成误操作。

深度解析：为何RAC集群中常出现“部分节点无法识别新磁盘”？

此问题通常并非ASM软件缺陷，而是源于RAC多节点环境下磁盘发现机制存在时序差异。典型症状为：集群中某一节点可在v$asm_disk中查询到新磁盘，而其他节点则始终无法发现，导致ADD DISK操作仅在部分节点生效，进而引发磁盘组状态不一致或挂起。

• 问题根源：主要原因包括：1) ASMLib驱动或UDEV持久化规则未在所有节点同步配置；2) 针对ASMLib，未在全部节点执行oracleasm scandisks命令；3) 对于UDEV，在规则更新后未在所有节点依次执行udevadm trigger与udevadm settle命令以重新触发设备事件并等待规则处理完成。
• 一致性验证方法：在集群每个节点上分别运行asmcmd lsdsk -k命令，对比输出的磁盘路径列表与权限信息。若存在差异，应立即检查/etc/udev/rules.d/99-oracle-asmdevices.rules文件内容的一致性，并确认systemctl status oracleasm（ASMLib）服务在各节点状态正常。
• 安全补救步骤：不建议直接重启集群高可用服务（ohasd）。更安全的做法是，针对识别异常的节点，使用srvctl stop asm -n 停止其ASM实例，再使用srvctl start asm -n 启动，以此强制重新扫描磁盘，此操作风险远低于重启整个集群。

ASM磁盘扩容完成后必须核查的两个隐蔽状态

在ADD DISK命令执行完毕且重平衡操作显示完成后，许多管理员便认为扩容已成功。然而，要确保ASM磁盘组达到真正稳定可用的状态，还需验证以下两个常被忽略的关键内部状态：

• 确认v$asm_operation视图已无记录：即使操作状态显示为SUCCESS，只要该视图中仍存在相关记录，即表明ASM内部元数据的同步或清理工作尚未完全结束。此时若尝试强制删除磁盘，极易触发ORA-15030（磁盘组操作正在进行）等错误。
• 验证v$asm_disk.header_status全部为MEMBER：若磁盘头状态仍为PROVISIONED（已配置）或CANDIDATE（候选），则表示该磁盘虽已加入磁盘组，但初始化或成员关系同步未彻底完成，后续I/O可能存在失败风险。此时，需手动执行ALTER DISKGROUP CHECK DISK ;命令进行检查与修复。

需要特别注意的复杂性在于：在RAC多节点环境中，上述状态视图的内容并非实时强一致同步。因此，务必在集群的每一个节点上分别登录ASM实例进行查询验证，绝不可仅凭单一节点的查询结果就断定整个集群的状态已完全正常。