ACFS本身不提供高可用，仅实现多节点共享文件系统；高可用需依赖ASM冗余、CRS资源管理及应用层适配。volcreate报ORA-15477首要原因是ADVM驱动未加载，须在各节点执行acfsload start并确认oracleadvm/oracleacfs模块已加载；ASM磁盘组compatibility必须≥11.2；ACFS挂载后须用srvctl注册为CRS资源，OGG等应用还需额外注册为CRS应用资源并设置启动依赖，否则仍为单点故障。
ACFS 本身不提供“高可用”逻辑，它只是让 RAC 多节点能同时读写同一份文件系统；真正的高可用依赖于底层 ASM 磁盘组冗余（如 NORMAL/ HIGH）+ CRS 资源管理 + 应用层适配（比如 OGG 注册为集群资源）。直接在裸 ACFS 上跑单点进程，照样单点故障。
volcreate 报 ORA-15477：ADVM 驱动未加载是首要拦路虎
这是最常卡住的一步。执行 volcreate 前必须确认 oracleadvm 和 oracleacfs 内核模块已加载，否则 ASM 根本无法创建卷。
- 检查命令：
lsmod | grep -E 'oracleadvm|oracleacfs'—— 缺任一模块都失败 - 加载命令（需 root，在每个 RAC 节点单独执行）：
/u01/app/19.3.0/grid/bin/acfsload start - 注意：RAC 所有节点都要做，不能只在 ASM 实例所在节点加载
- 常见错误现象：
ORA-15032: not all alterations performed+ORA-15477: cannot communicate with the volume driver
ASM 磁盘组 compatibility 必须 ≥ 11.2 才支持 ADVM/ACFS
低于该版本的磁盘组无法启用 ADVM 卷功能，volcreate 会静默失败或报权限类错误。
- 检查 SQL：
SELECT name, compatibility FROM v$asm_diskgroup; - 升级兼容性（需停业务评估）：
ALTER DISKGROUP <dg_name> SET ATTRIBUTE 'compatible.asm' = '12.1.0.0.0'; - 注意：
compatible.rdbms不影响 ACFS，只看compatible.asm - 若磁盘组由 11g RAC 创建，默认可能是 11.2.0.0.0，但某些一键脚本可能设为 10.1.0.0.0，必须显式升级
挂载 ACFS 后必须注册进 CRS 才能跨节点自动接管
手动 mount -t acfs 只在当前节点生效，节点宕机后不会自动在另一节点挂载，也无法被 CRS 管理。
- 注册命令（grid 用户执行）：
srvctl add filesystem -d /dev/asm/<volname>-<num> -g <diskgroup> -m <mount_point> -u <owner> - 启动服务：
srvctl start filesystem -d /dev/asm/<volname>-<num> - 验证状态：
crsctl stat res -t | grep acfs，应显示 ONLINE 并关联到所有节点 - 漏掉注册 → OGG 安装目录虽在 ACFS 上，但进程仍属单节点管理，CRS 不感知、不拉起、不故障转移
OGG 部署在 ACFS 上 ≠ 自动高可用，必须额外注册为 CRS 应用资源
ACFS 提供共享存储，但 OGG 进程本身仍是普通 Linux 进程。要实现故障时自动漂移到存活节点，必须用 srvctl add application 或 XAG 封装。
- 典型做法：将
mgr、extract、replicat分别注册为 CRS 资源，设置START_DEPENDENCIES=hard(fs:ogg_fs) - 关键点：启动顺序依赖 ACFS 挂载资源，且需指定
-n绑定到特定节点或允许 failover - 若仅把软件解压到 ACFS，用 crontab 或 systemd 启动 —— 这和本地文件系统无异，完全不具备 RAC 级高可用能力
- 生产环境强烈建议配合
acfsutil registry -a记录挂载信息，并定期acfsutil info fs检查一致性
真正容易被忽略的是：ACFS 的“共享”只解决存储可见性，不解决进程生命周期管理。从 volcreate 到 OGG 注册为 CRS 资源，中间每一步断链，高可用就归零。尤其 acfsload 是否成功、srvctl add filesystem 是否执行、srvctl add application 是否带依赖，这三个动作缺一不可。
