TFA未自动清理旧日志因默认仅清理trace/alert/core（保留30天），incident/hm/ir目录不清理，且依赖的tfa_storage元数据库损坏或tfa进程未运行会导致清理静默失效。
为什么 tfa 没有自动清理旧日志？
默认情况下 tfa 确实会轮转和压缩日志，但「自动清理」只针对 trace、alert、core 这几类文件，且仅保留最近 30 天（可配置）；而 diag 下的 incident、hm、ir 目录里的内容默认不被清理——这些目录常因频繁 ora-600/ora-7445 被撑爆。
更关键的是：tfa 的清理策略依赖于它自己维护的元数据库（tfa_storage），一旦该库损坏或未正常启动，整个清理逻辑就静默失效。
-
tfa进程必须运行（检查ps -ef | grep tfa） - 确认清理策略已启用：
$TFA_HOME/bin/tfactl print config | grep cleanup，输出应含cleanup.enabled=true - 若输出为
false或无此行，需手动开启：$TFA_HOME/bin/tfactl configure -cleanup true - 注意：该命令需在所有 RAC 节点分别执行，且会触发
tfa重启
如何安全释放 tfactl 占用的磁盘空间？
别直接 rm -rf tfactl 目录下的子目录——tfa 正在监控并索引这些路径，硬删会导致元数据错乱，后续 tfactl view 报错或漏日志。
正确做法是让 tfa 主动归档 + 清理：
- 强制触发一次完整清理：
$TFA_HOME/bin/tfactl cleanup -all -force（耗时较长，建议在低峰期跑） - 如空间已紧急告警（
/u01使用率 >95%），先临时禁用采集以止血：$TFA_HOME/bin/tfactl disable collection - 清理完再恢复：
$TFA_HOME/bin/tfactl enable collection - 检查清理结果：
$TFA_HOME/bin/tfactl view cleanuphistory，确认Status为SUCCESS
tfa 清理范围与 Oracle 版本差异
不同版本 tfa 对 diag 子目录的处理逻辑不同。12.2.1.1+ 默认跳过 incident，但 19c 的 tfa 19.12+ 已支持配置 incident.retention.days ——这点极易被忽略，导致误以为「清理没生效」。
- 查当前支持的清理项：
$TFA_HOME/bin/tfactl print cleanupconfig - 若想清理
incident，需显式设置：$TFA_HOME/bin/tfactl configure -cleanup_incident true -incident_retention_days 15 - 注意：该配置仅对新生成的 incident 生效，已有大量旧 incident 需先用
tfactl cleanup -all扫描识别后才纳入清理范围 - RAC 环境下，所有节点的
tfa版本必须一致，否则清理策略同步失败（常见报错：Node xxx has different TFA version）
清理后仍反复爆满？重点盯这三个地方
多数人清完一次就以为搞定，但一周后又报警——往往不是 tfa 问题，而是底层 Oracle 实例持续产生异常诊断数据。
- 查高频 incident：
adrci> show incident -mode detail -p "CREATE_TIME > '2024-01-01'" | grep -E "(INCIDENT_ID|PROBLEM_KEY)"，看是否集中某类 ORA- 错误 - 检查
AWR中DB Time和SQL*Net break/reset是否突增——网络抖动或应用未正确关闭连接，会引发大量ORA-1089并触发 incident - 确认
diagnostic_dest是否指向了小容量文件系统：show parameter diagnostic_dest；若/u01不够大，别只调tfa，得改 Oracle 的DIAGNOSTIC_DEST或挂载更大存储
真正麻烦的从来不是怎么删日志，而是删完第二天又有 500 个新 incident 冒出来——这时候该翻 adrci 而不是再敲一遍 tfactl cleanup。
