“叮！/oracle 目录使用率 100%！”
作为一个数据库管理员，这行报警短信绝对比女朋友的“我们谈谈”还要让人心跳骤停。
昨天我就经历了这么一遭。正准备摸鱼喝口咖啡，监控系统突然发难。上服务器一看，好家伙，/oracle 目录红得刺眼，直接顶满。
这就好比你刚买的 512G 手机，一夜之间被塞满，还不知道是谁干的。
01 案发现场：谁吃了我的空间？
通常来说，Oracle 目录满了，嫌疑人无非就是那几个：归档日志（Archive Logs）、Trace 文件，或者是审计日志。
我熟练地敲下 du 命令，准备揪出元凶。
结果一路追踪下去，发现嫌疑人竟然藏在 $ORACLE_HOME/crf/db 这种平时根本不会多看一眼的角落里。
罪魁祸首锁定： crfclust.bdb
这兄弟体型人，凭一己之力撑爆了整个分区。
02 嫌疑人档案：CHM 是个什么鬼？
查了一下 MOS (My Oracle Support)，原来这是 CHM (Cluster Health Monitor) 搞的鬼。
听听这名字，“集群健康监控”，本来是用来监控数据库健康的，结果它自己先“病”了。这就好比那个只拿钱不干活还偷吃家里大米的保安。
简单说： 这是一个已知的 Bug。CHM 服务没关好，导致这个 bdb 文件像贪吃蛇一样无限生长，直到把磁盘撑死。
03 暴力执法：删库（文件）跑路？不，是修复！
既然找到了赖着不走的大胖子，解决办法就很简单粗暴了。官方给了两条路：
1、打补丁（流程繁琐，还要申请停机窗口，累）。
2、直接干掉文件，重启服务（简单粗暴，深得我心）。
毫不犹豫，我选择了方案二。
第一步：确认嫌疑人状态
先看看这个 ora.crf 服务是不是还活着。
[grid@s1-11g bin]$ crsctl stat res ora.crf -init -t -------------------------------------------------------------------------------- NAME TARGET STATE SERVER STATE_DETAILS -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.crf ONLINE ONLINE s1-11g
看到 ONLINE 了吗？还在搞。
第二步：让他闭嘴（停止服务）
为了安全删除文件，得先让服务停下来。
[grid@s1-11g bin]$ crsctl stop res ora.crf -init CRS-2673: Attempting to stop 'ora.crf' on 's1-11g' CRS-2677: Stop of 'ora.crf' on 's1-11g' succeeded
第三步：清理门户（删除大文件）
高能预警：执行 rm -rf 时请保持清醒，手别抖，一定要确认路径！
# 切换到 root 用户进入目录 cd $ORACLE_HOME/crf/db/$HOMENAME/ # 它是真的大，删了它！ rm -rf crfclust.bdb
删完之后，那一瞬间的快感……懂的都懂。再次执行 df -h：
[root@s1-11g s1-11g]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_s111g-LogVol03
21G 12G 8.2G 58% /oracle
使用率从 81% 降到了 58%，舒服了！这感觉就像便秘三天终得解脱。第四步：既往不咎（重启服务）
虽然它惹了祸，但作为系统服务，还是得把它拉起来（当然，如果你就是不想开它，这步也可以省略，但为了规范还是开启为妙）。
[grid@s1-11g bin]$ crsctl start res ora.crf -init CRS-2672: Attempting to start 'ora.crf' on 's1-11g' CRS-2676: Start of 'ora.crf' on 's1-11g' succeeded
如果你是 RAC 环境，别忘了其他节点也要检查一遍！我就顺手把节点二也清理了，腾出了十几个 G 的空间。
好了，警报解除，接着喝咖啡去了。☕️
本文纯属技术分享，操作生产环境前请务必备份，手抖概不负责（狗头）。
