srvctl stop asm 卡住或报 ORA-15032/ORA-15063 是因 ASM 仍被数据库、ACFS 或挂载点强依赖，Clusterware 为防数据不一致而阻塞；须先停数据库、卸载 ACFS、确认磁盘组未被使用，再执行 srvctl stop asm。

srvctl stop asm 为什么会卡住或报错 ORA-15032/ORA-15063

执行 srvctl stop asm 卡在“waiting for asm instance to shut down…”或者直接报 ora-15032: not all alterations performed、ora-15063: asm discovered an insufficient number of disks，本质不是 asm 没停，而是它还在被其他资源强依赖——比如数据库实例、acfs 文件系统、甚至某个没显式注册的磁盘组挂载点。

Oracle Clusterware 要求 ASM 实例必须“干净退出”，即所有依赖它的资源已先停止并解除关联。否则 srvctl 会主动阻塞，防止误操作导致数据不一致。

• 检查依赖：运行 crsctl stat res -t | grep -E "(asm|ora\.)"，重点看状态为 ONLINE 的数据库资源（如 ora.db1.db）是否还连着这个 ASM
• 确认磁盘组使用情况：用 sqlplus / as sysasm 连上 ASM，查 SELECT name, state, type FROM v$asm_diskgroup;，若某 diskgroup 是 MOUNTED 但实际被 ACFS 或 DB 在用，srvctl stop asm 就不会推进
• ACFS 必须先卸载：如果用了 ACFS，得先在所有节点执行 sudo umount /u01/app/acfsmounts/vol1（路径以 acfsutil info fs 输出为准），再 acfsutil registry -d 注销

srvctl stop asm -f 强制停止的风险与适用场景

srvctl stop asm -f 会跳过依赖检查，直接发 SHUTDOWN ABORT 给 ASM 实例。这不是“重启捷径”，而是故障恢复手段——只应在确认无活跃数据库、无 ACFS 挂载、且磁盘组无写入时使用。

强行终止后，下次启动 ASM 可能触发磁盘组 recovery，尤其当 ASM 有未刷盘的 allocation unit 修改时，ALTER DISKGROUP ... MOUNT 可能卡住或报 ORA-15033。

• 强制前必查：ps -ef | grep pmon | grep -v grep 确保没有数据库实例在运行
• 强制后必须验证磁盘组：启动 ASM 后立即运行 ALTER DISKGROUP ALL CHECK;，观察 alert.log 是否有修复日志
• 不要在 RAC 多节点环境中只对单节点 -f：可能造成节点间 ASM 元数据视图不一致，引发 voting disk 访问异常

重启 ASM 的正确顺序：先清依赖，再启 ASM，最后拉起数据库

ASM 不是独立服务，它是整个 Oracle Cluster 的存储底座。重启它必须按依赖拓扑反向操作：数据库 → ACFS → ASM →（可选）监听器/SCAN。

典型安全流程是三步走，缺一不可：

• 停数据库：srvctl stop database -d orcl（orcl 是 DB 名，非实例名）
• 停 ACFS（如有）：acfsutil registry -u + umount（每个挂载点单独处理）
• 停 ASM：srvctl stop asm -n node1（-n 指定节点，RAC 中不能省略）；确认状态为 OFFLINE 后再 srvctl start asm -n node1

漏掉任意一步，srvctl start asm 可能看似成功，但后续数据库启动时会报 ORA-15100: no diskgroups mounted 或连接 ASM 实例超时。

为什么 srvctl stop asm 不等于 shutdown immediate？

srvctl 是 Clusterware 层的资源管理命令，它调用的是 CRS API，不是直接发 SQL。即使你手动进 ASM 实例执行了 SHUTDOWN IMMEDIATE，crsctl stat res ora.asm 仍显示 ONLINE，因为 Clusterware 不知道底层状态已变——它只认自己维护的资源状态机。

这就导致两个常见陷阱：

• 手动 shutdown 后直接 srvctl start asm：Clusterware 认为 ASM 还在运行，拒绝启动，报 CRS-2632: There are no more servers to try to place service
• 手动 shutdown 后用 crsctl stop res ora.asm：绕过 srvctl 校验，但可能留下资源锁或 OCR 不一致，下次 crsctl start crs 会失败
• 真正该做的是：始终用 srvctl 管理生命周期，手动 SQL 只用于诊断（如查 v$asm_client 确认谁连着）

ASM 实例的“重启”从来不是孤立动作，它嵌在整个集群资源依赖图里。少看一个 crsctl stat res 输出，就可能多花两小时排查磁盘组挂不上。