在Oracle RAC环境中，ASM作为裸设备之上的存储管理方案，天生就是为数据文件、控制文件、联机日志这些数据库对象设计的。但现实运维中总有 ASM 覆盖不到的需求：归档日志要放共享位置、GoldenGate 的 trail 文件需要多节点同时读写、甚至只是一些安装介质和脚本想集中存放。ASM 磁盘组里的内容普通文件系统命令根本看不到，这时候 ACFS 就派上用场了。ACFS 的全称是 Oracle Automatic Storage Management Cluster File System，它是 Oracle 提供的集群共享文件系统，而且它的存储底座正是 ASM 磁盘组，两者互操作是这个方案的核心。
一、ACFS 与 ASM 互操作的底层架构
很多DBA第一次接触 ACFS 时都会疑惑：文件系统怎么建在磁盘组上？磁盘组不是只能给数据库用吗？要理解这个互操作，必须先理清 ASM、ADVM、ACFS 三层的职责划分。ASM 位于最底层，负责管理磁盘、做条带化和镜像冗余；ADVM（ASM Dynamic Volume Manager）是中间层，它在一个 ASM 磁盘组内部划出一块空间，以卷的形式对外暴露，在操作系统中表现为 /dev/asm/卷名-数字 这样的块设备；ACFS 则是最上层的通用文件系统，直接创建在 ADVM 卷之上，提供 POSIX 兼容的文件操作接口。
这个链路的加载顺序也有讲究。Linux 上 ACFS 依赖内核模块 oracleacfs 和 oracleadvm，这两个模块由 OHASD 托管的资源负责加载。也就是说，只要 Grid Infrastructure 正常启动，模块加载、卷设备的创建、文件系统挂载都可以交给集群软件自动完成，不需要管理员手动写 fstab。这一点和传统的 NFS 或 GPFS 有本质区别，ACFS 的生命周期是跟着 GI 走的。
还有一点容易忽略：存放 ACFS 卷的磁盘组属性有要求，磁盘组的兼容性参数 compatible.advm 必须设置到 11.2 及以上，否则卷创建会直接报错。日常建议为 ACFS 单独建一个外部冗余的磁盘组，而不是和数据文件混在同一个磁盘组里，便于容量规划和性能隔离。
二、从磁盘组到挂载点的完整配置流程
下面以一个实际场景为例：在两节点 RAC 上创建一个供归档日志使用的共享 ACFS。第一步先创建磁盘组并设置 ADVM 兼容性参数，用 grid 用户执行：
-- 创建专用磁盘组，compatible.advm 是关键参数
CREATE DISKGROUP ACFSDG EXTERNAL REDUNDANCY
DISK '/dev/asm-disk5'
ATTRIBUTE
'compatible.asm' = '19.0.0.0',
'compatible.advm' = '19.0.0.0';第二步创建 ADVM 卷。卷必须建在设置了 compatible.advm 的磁盘组中，大小可以指定，也可以后期在线扩容：
# 用 grid 用户执行，创建 100G 的卷 asmcmd volcreate -G ACFSDG -s 100G ARCHVOL # 查看卷信息，确认卷设备名 asmcmd volinfo -G ACFSDG ARCHVOL # 输出中的 Device Name 类似 /dev/asm/archvol-123
第三步创建文件系统并挂载。注意创建文件系统用 grid 用户即可，但挂载动作需要 root 权限：
# 创建 ACFS 文件系统 /sbin/mkfs -t acfs /dev/asm/archvol-123 # root 用户在两个节点分别执行挂载 mkdir -p /archlog /sbin/mount -t acfs /dev/asm/archvol-123 /archlog # 授权给 oracle 用户 chown oracle:oinstall /archlog
第四步是互操作中最重要的环节：把挂载动作注册成 CRS 资源。手动挂载在节点重启后会失效，而且 CRS 感知不到，节点驱逐时可能出问题。正确的做法是注册资源：
# 注册 ACFS 挂载资源，所有节点自动维护 srvctl add filesystem -device /dev/asm/archvol-123 \ -path /archlog -user oracle # 启动资源，CRS 会在集群各节点自动挂载 srvctl start filesystem -device /dev/asm/archvol-123
注册完成后，可以用 crsctl stat res -t 看到该资源处于 ONLINE 状态，此时在任一节点写入的文件，另一个节点立即可见，这就是集群文件系统的价值所在。
三、生产环境常见坑点与运维建议
第一个坑是版本与平台限制。ACFS 在早期版本对 GI 和数据库版本有严格的互操作矩阵，比如 11.2 早期补丁集下 ACFS 数据库文件支持有限，直到 12.1 之后才全面放开。部署前务必查 MOS 上对应版本的认证矩阵，确认自己的操作系统内核也在支持列表里，否则模块加载会失败。Windows 平台上的 ACFS 行为与 Linux 差异较大，迁移方案时要特别留意。
第二个坑是删除顺序。很多人清理 ACFS 时直接把磁盘组 drop 掉，结果留下悬空的挂载点，导致节点重启时 CRS 卡住。正确的拆除顺序是：先删 CRS 资源，再卸载所有节点的文件系统，然后删除卷，最后才处理磁盘组：
# 严格的拆除顺序，顺序颠倒会留下悬空资源 srvctl stop filesystem -device /dev/asm/archvol-123 srvctl remove filesystem -device /dev/asm/archvol-123 umount /archlog asmcmd voldelete -G ACFSDG ARCHVOL asmcmd dropdg ACFSDG
第三个坑是空间与快照管理。ACFS 卷虽然支持在线扩容（asmcmd volresize 配合 acfsutil size），但缩容有限制，规划容量时宁可给足。另外 ACFS 自带快照能力，命令是 acfsutil snap create，做归档日志备份前的临时保护非常实用，比传统 cp 快得多。日常监控方面，建议用 acfsutil info fs 定期采集使用率，纳入监控平台，避免磁盘组悄悄写满波及同组的其他卷。
总体来说，ACFS 与 ASM 的互操作让 RAC 的存储能力从数据库对象延伸到了通用文件领域，架构上是层层递进的关系：磁盘组承载卷，卷承载文件系统，CRS 负责全生命周期托管。只要把兼容性参数、资源注册和拆除顺序这几个关键点守住，ACFS 完全可以成为 RAC 环境中处理共享文件的首选方案，比外挂 NFS 少一套依赖，管理上更省心。
Oracle RACACFS文件系统ASM磁盘组修改时间：2026-09-09 08:48:43