oracle rac节点/u01盘满会直接导致集群崩溃，主因是ora.crf服务受bug 10165314影响生成超60g的.bdb文件，触发ohasd反复重启、阻塞ora.asm等关键资源，同时tmpfs型/tmp满或tfa未清理亦会硬性中断crs初始化。
Oracle RAC节点本地盘（如/u01）空间满，不是“可能”导致集群崩溃，而是会直接触发关键守护进程失败、资源无法启动或被强制驱逐——尤其是当满的是Grid Infrastructure安装目录所在分区时。
ora.crf服务写爆/u01引发连锁反应
CHM（Cluster Health Monitor）的ora.crf服务默认将监控数据存放在$GRID_HOME/crf/db/$HOSTNAME/下，文件名形如crfclust.bdb。它本应受oclumon manage -get repsize限制（默认1G），但存在已知BUG（MOS ID 10165314），会导致.bdb文件无节制增长——实测单个文件超60G很常见。一旦/u01被撑到100%，ora.crf自身写入失败，OHASD会反复尝试重启该资源，同时阻塞其他依赖它的资源（如ora.asm、ora.cluster_interconnect.haip）上线。
-
crsctl stat res -t中可见ora.crf状态在OFFLINE/INTERMEDIATE间震荡 -
tail -n 50 $GRID_HOME/log/$HOSTNAME/crsd/crsd.log里频繁出现CLSGPNP_ERR或IO error writing to bdb file - 后续
ora.asm因等待ora.crf就绪超时而启动失败，整个节点CRS堆栈挂起
tmpfs类型的/tmp满直接卡死ASM与CRS
若/tmp是tmpfs（内存文件系统），且被占满，后果比普通磁盘满更严重：ASM实例无法创建临时段、OHASD无法生成IPC socket、root.sh执行中途失败都会发生。这不是警告，是硬性阻断。
- 现象包括：
ORA-01114（write failed:No space left on device）、CRS-4535（Cannot communicate with Cluster Ready Services）、ORA-29701（unable to connect to Cluster Synchronization Services） -
df -h /tmp显示Use%为100%，且Type列为tmpfs - 此时即使
/u01还有空间，CRS也无法完成初始化——因为/tmp是OHASD和CSSD的运行时工作区
TFA日志未清理导致/u01静默耗尽
TFA（Trace File Analyzer）默认只清理trace/alert目录，但incident、hm、ir目录长期不处理。尤其在频繁报ORA-600的环境中，这些目录可轻松突破20G。而TFA的元数据库tfa_storage损坏后，清理逻辑完全静默失效，管理员毫无感知。
- 检查命令：
$TFA_HOME/bin/tfactl print cleanupconfig，确认cleanup_incident是否为true - 紧急释放空间不能
rm -rf，必须用：$TFA_HOME/bin/tfactl cleanup -all -force - RAC所有节点TFA版本必须一致，否则
tfactl configure在某节点生效，其他节点仍按旧策略跑
真正危险的不是某个目录满了，而是多个组件（CHM、TFA、tmpfs）共享同一挂载点，且故障表现延迟——比如CHM文件今天长到90%，明天突然写满最后1G，瞬间击穿整个CRS堆栈。修复后务必验证oclumon manage -repos changesize 2G是否生效，并确认$GRID_HOME/crf/db下最大文件不超过2G。
