ACFS（Oracle Automatic Storage Management Cluster File System）是Oracle基于ASM磁盘组构建的集群文件系统，广泛用于存放共享文件、软件介质、备份文件等场景。和普通文件系统不同，ACFS的运行状态与Grid Infrastructure紧密耦合，一旦出现挂载失败、资源offline或者节点重启等问题，相关线索往往分散在操作系统日志和集群日志两个层面。很多初学者只知道去看alert日志，结果找不到关键信息，白白浪费排查时间。本文系统整理ACFS相关的各类日志位置和排查思路，帮助大家快速定位问题。
一、ACFS相关的操作系统层日志
ACFS在Linux平台上依赖内核模块驱动，驱动的名字通常为oracleacfs、oracleadvm、oracleoks。这些驱动加载、卸载或者报错时，信息会直接写入操作系统日志。在RHEL和CentOS系统上，对应的位置一般是/var/log/messages，部分新版本系统则统一由systemd journal管理，可以使用journalctl -k过滤内核信息。
排查ACFS问题时，建议先在操作系统日志中按关键字过滤，例如acfs、advm、oks等。驱动加载失败的典型报错包括模块不存在、版本与内核不匹配等，这类问题不会体现在数据库告警日志中，只能通过操作系统日志发现。如果ACFS挂载点突然无法访问，或者使用dmesg查看输出中发现大量acfs相关的错误堆栈，基本可以判断是驱动层面出了问题，常见于内核升级后没有重新执行acfs脚本注册驱动模块。
另外，驱动状态可以通过lsmod命令确认，结合操作系统日志一起看能快速判断ACFS子系统是否正常运行：
# 查看ACFS相关内核模块是否加载 lsmod | grep oracle # 查看ACFS文件系统加载工具输出 ls /sbin/fsck.acfs /sbin/mount.acfs 2>/dev/null # 过滤操作系统日志中的ACFS错误 grep -i "acfs\|advm\|oks" /var/log/messages | tail -50
如果发现模块未加载，可以手动执行/u01/app/19.0.0/grid/bin/acfsload start -s（路径按实际Grid HOME调整），同时观察messages日志中模块加载的返回结果。
二、Grid Infrastructure层的关键日志
ACFS资源由Grid Infrastructure统一管理，因此GI层面的日志是排查ACFS问题的核心。首先要看的是alert日志，也就是$GRID_BASE/diag/crs/<节点名>/crs/trace/alert.log。ACFS文件系统资源（如ora.data.acfs类型资源）的启动、停止、online、offline动作都会在这个日志中留下记录，包括执行mount.acfs时抛出的错误信息。
除了alert日志，还需要关注crsd的trace文件，路径在$GRID_BASE/diag/crs/<节点名>/crs/trace/目录下，常见文件包括crsd_oraagent_grid.trc等。当ACFS资源启动失败时，oraagent会反复尝试拉起资源，失败的原因会详细记录在trace文件中，比如磁盘组未挂载、ASM实例异常、挂载点目录不存在或权限不对等。
查看ACFS资源状态时，先确认资源是否注册并且处于online状态：
# 查看ACFS资源状态 crsctl stat res -t | grep -A 2 acfs # 查看某个ACFS资源的详细属性 crsctl stat res ora.data.acfs -p # 手动启动ACFS资源并观察结果 crsctl start res ora.data.acfs -n racnode1
还有一个容易被忽略的日志是ohasd相关trace。如果节点重启后ACFS没有自动挂载，问题可能出在ohasd启动阶段，比如依赖的ASM磁盘组还没online，ACFS资源就被尝试启动。这种情况下alert日志中会出现资源启动依赖失败的记录，解决办法一般是检查资源配置中的依赖关系，或者在重新配置ACFS资源时确保依赖了正确的磁盘组资源。
三、ACFS自身的专用日志与常用排查命令
ACFS自身也提供了一部分日志输出。在较新版本中，ACFS的事件日志位于/var/opt/oracle/log/或者/var/log/acfslog（具体路径因版本和平台略有差异），其中记录了ACFS驱动事件、注册信息以及部分挂载卸载动作。此外，ACFS审计和事件功能可以通过acfsutil工具开启，开启后的事件日志存放在文件系统内部，路径一般是挂载点下的.ACFS/隐藏目录中，可用于追踪文件级别的变更。
日常运维中，acfsutil是使用频率最高的工具集，配合日志可以完成大部分问题的定位：
# 查看ACFS文件系统基本信息 acfsutil info fs /acfs_data # 查看挂载的ACFS卷和磁盘组 acfsutil info mount # 查看ACFS注册信息（取代旧版本的注册表方式） acfsutil registry -l # 开启事件日志，便于追踪文件操作 acfsutil log -m /acfs_data all all
排查ACFS扩容失败时，可以先用acfsutil info fs查看当前大小和空闲空间，再结合ASM层面的磁盘组空间判断瓶颈。如果扩容命令返回错误，alert日志和操作系统日志中通常会有对应的错误码，比如ORA-15437之类，表示磁盘组空间不足或者ADVM卷状态异常。
遇到日志没有输出的情况，还要检查几点：一是Grid的trace级别可能被调低了，可以用crsctl set log临时提高资源代理的日志级别；二是确认查看的确实是问题发生节点的日志，ACFS问题往往只出现在单个节点；三是时间线要对齐，建议用date确认各节点时间同步情况，否则跨节点比对日志时容易误判因果关系。按照操作系统日志、GI的alert与trace、ACFS专用日志这个顺序逐层排查，绝大多数ACFS问题都能快速找到根因。
Oracle RACACFS文件系统日志排查修改时间：2026-09-13 10:02:34