ACFS在19c RAC中必须通过ADVM卷间接构建，需所有节点加载内核模块、注册资源并统一挂载；跳过任一环节将导致ORA-15477错误或重启后丢失。
ACFS在19c RAC中不能直接用mkfs或mount命令裸操作——它必须通过ASM卷（ADVM）间接构建，且所有节点需同步加载驱动、注册资源、挂载一致。跳过任一环节都会导致挂载失败或重启后丢失。
确认ACFS/ADVM内核模块已加载（所有RAC节点）
这是最常被忽略的前置条件：19c RAC虽自带驱动，但重启后不会自动加载，lsmod | grep -i acfs为空即代表模块未就绪，后续所有操作都会报ORA-15477: cannot communicate with the volume driver。
- 以root身份执行：
/u01/app/19.3.0/grid/bin/acfsload start（路径按实际GI_HOME调整） - 验证输出含
ACFS-9308: Loading installed ADVM/ACFS drivers和ACFS-9322: completed - 检查结果：
lsmod | grep -E "(oracleacfs|oracleadvm)"应返回两行非空输出 - 注意：该命令需在每个节点单独运行，且不能由
grid用户执行
创建ADVM卷并格式化为ACFS文件系统
ACFS不直接作用于ASM磁盘组，而是依赖ADVM卷作为中间层。卷名、大小、磁盘组名必须全小写，否则volcreate会静默失败或挂载时路径解析异常。
- 进入ASMCMD（以
grid用户）：asmcmd - 创建卷（例如在
DATADG中建50G卷）：volcreate -G datadg -s 50G acfs_vol1 - 确认卷存在：
volinfo -G datadg acfs_vol1，输出中Volume Device字段即为OS设备路径（如/dev/asm/acfs_vol1-488） - 格式化（在任意一个节点执行即可）：
mkfs -t acfs /dev/asm/acfs_vol1-488 - 注意：
mkfs.acfs命令在19c中已被弃用，直接用mkfs -t acfs；若提示“invalid argument”，大概率是卷未激活或模块未加载
注册、挂载并加入集群管理（ora.registry.acfs）
仅格式化+手工mount是临时的，节点重启后失效。必须注册到Oracle Cluster Registry（OCR）并通过CRS托管，才能实现自动挂载与故障转移。
- 所有节点创建挂载点（权限建议
755，属主按用途设，如OGG用oracle:oinstall）：mkdir -p /ogg - 注册文件系统（以
root执行）：/u01/app/19.3.0/grid/bin/acfsreg -a /dev/asm/acfs_vol1-488 /ogg - 启动挂载服务：
crsctl start resource ora.registry.acfs - 验证状态：
crsctl stat res -t | grep registry应显示ONLINE且目标为ONLINE - 关键点：注册后
/etc/oracle/acfsregistry会自动生成条目，不可手动编辑；若误删，需先acfsunreg再重注册
验证跨节点可见性与持久性
ACFS不是“挂上就完事”，真正的共享能力体现在：两个节点同时看到相同内容、写入后对方立即可见、重启后仍自动挂载。
- 在节点1写测试文件：
echo "node1" > /ogg/test.txt - 立刻在节点2读取：
cat /ogg/test.txt—— 必须输出node1，否则ADVM卷未真正共享或权限受限 - 重启任一节点，检查
df -h | grep acfs是否仍包含/ogg，且crsctl stat res ora.registry.acfs为ONLINE - 常见陷阱：挂载点目录权限为
700且属主非grid时，CRS可能无法完成挂载；acfsutil info fs可查看详细挂载状态与集群模式
ACFS的复杂性不在命令本身，而在于它横跨ASM、内核模块、CRS三套机制。任何一个环节脱节（比如忘了在节点2执行acfsload start），都会让整个共享链路中断，且错误日志分散在asmalert.log、crsctl stat输出、dmesg里，排查成本远高于预防。务必把模块加载和资源注册当作部署流水线的强制关卡，而不是“试试看”的可选步骤。
