不能直接用于RAC环境——tfactl diagcollect默认仅采集当前节点日志，不感知RAC多节点架构；必须使用tfactl diagcollect -all（需root SSH免密）或手动逐节点采集并合并。
tfactl diagcollect 命令到底能不能直接用于 RAC 环境
不能直接用——tfactl diagcollect 默认只采集当前节点的本地日志，对 rac 多实例、多节点、共享存储的架构完全无感知。强行在某个节点执行，结果就是：缺 ocr/voting disk 日志、缺其他节点的 alertrac.log、缺 gpnp/olr 配置快照，sr 提交后 oracle 支持第一句大概率是“请补全集群范围诊断包”。
实操建议：
- 必须先用
tfactl status确认所有节点在线且tfactl服务正常（常见坑：某节点tfactl进程僵死但状态显示 green） - 真正有效的命令是带
-all参数的集群级采集：tfactl diagcollect -all - 该命令会自动 SSH 到每个节点并行执行本地
diagcollect，再汇总打包——前提是各节点 root 用户 SSH 免密已配置（否则卡在连接环节） - 若免密未配，得先手工在每个节点分别运行
tfactl diagcollect，再手动合并/opt/oracle.ahf/data/<hostname>/diagcollection/</hostname>下的 tar.gz 包
RAC 场景下哪些日志会被 tfactl 自动漏掉
tfactl diagcollect -all 虽然覆盖了 CRS、ASM、DB 实例日志，但以下三类关键数据默认不包含，必须额外手动补充：
- OCR 和 Voting Disk 的物理块信息：
ocrcheck -details、crsctl query css votedisk输出需截图或重定向保存 - 集群网络配置快照：
oifcfg getif、cluvfy comp nodecon -n all -verbose结果必须包含在 SR 附件中 - 最近一次 OCR 自动备份文件（通常在
+GRID:/OCRBACKUP/或$ORACLE_HOME/cdata/<cluster_name>/），tfactl不读 ASM 中的备份镜像
生成的 diagcollection.tar.gz 里最关键的三个目录结构
解压后重点盯这三个路径，它们决定支持工程师能否快速定位问题根源：
-
/diagcollection/<hostname>/crs/<timestamp>/：含alertrac.log、ocssd.trc、ohasd.trc，RAC 启动失败时优先查这里 -
/diagcollection/<hostname>/asm/<timestamp>/：含alert_+ASM1.log和 ASM trace 文件，磁盘组挂载异常必看 -
/diagcollection/<hostname>/database/<db_unique_name>/<timestamp>/：注意不是ORACLE_SID，而是DB_UNIQUE_NAME，RAC 中可能有多个不同名的数据库实例
提交 SR 前必须校验的三个硬性条件
Oracle 支持团队拒收包的高频原因就这三项，现场常被忽略：
- 打包时间戳必须覆盖问题发生窗口：用
ls -lt /opt/oracle.ahf/data/*/diagcollection/确认最新包的生成时间是否晚于故障时刻 - 所有节点的 AHF 版本必须一致：
tfactl version输出的 build number 在各节点要完全相同，版本混用会导致日志解析错位 - 压缩包内不能有空目录或损坏的 .trc 文件：用
tar -tzf diagcollection.tar.gz | grep "\.trc$" | head -5快速抽检几个 trace 是否可列出
最麻烦的其实是 OCR 备份和网络校验这两块——没人盯着的话，很容易以为 tfactl diagcollect -all 一跑就万事大吉，结果 SR 被打回来重提两次。
