必须用 tfactl diagcollect -srdc 当mos明确要求srdc格式诊断包时，因其含必需元数据头、自动包含osw数据、去重日志并校验crs事件，普通diagcollect不被mos自动识别。
什么时候必须用 tfactl diagcollect -srdc？
当oracle支持（mos）明确要求你提供“srdc格式”诊断包时，tfactl diagcollect -srdc 是唯一合规方式。这不是可选项——普通 diagcollect 生成的zip包不带srdc元数据头，上传到mos后无法被自动诊断引擎识别，工程师得手动解压、定位日志，拖慢整个sr处理流程。
常见触发场景包括：集群节点失联、ASM磁盘组挂起、CRS资源反复offline、或MOS回复中直接写明“Please collect SRDC using TFA”。注意：-srdc 不是“更高级的收集”，而是“符合Oracle后台分析协议的格式”。
-
-srdc必须在 root 用户下运行（即使TFA本身由oracle/grid用户安装），否则会报Permission denied: /opt/oracle/tfa/.../srdc - 它默认收集所有节点（
-node all），不加参数不会只收当前节点 - 若指定组件（如
-srdc dbasm），只会打包ASM+DB相关日志，但SRDC结构仍完整，MOS可解析
tfactl diagcollect -srdc 和普通 diagcollect 的关键区别
核心差异不在内容多少，而在封装逻辑和元信息。普通 diagcollect 是“把日志打包发给你看”，-srdc 是“把日志+上下文+时间锚点+组件拓扑一起编码成机器可读的诊断单元”。MOS后台系统依赖SRDC头里的 collection_time、cluster_name、node_list 等字段做自动关联分析。
- 普通收集可能漏掉
oswbb归档（除非显式加-osw），而-srdc默认包含最近24小时OSWatcher数据（如果已部署） -
-srdc会强制 trim 掉重复日志块（比如同一错误在alert.log里刷屏100次，只留首尾3条），普通模式需手动加-trim - 时间范围参数（
-from/-to）对两者都生效，但-srdc会额外校验该时间段内是否有CRS重启事件，并自动补全对应crflog
实操中90%的人卡在权限和路径上
TFA不是“装完就能用”的工具——它依赖节点间SSH信任和统一TFA_HOME。很多RAC环境里，grid用户能ssh到其他节点，但root不能；或者TFA只在Node1装了，Node2没同步，导致 -srdc 执行到一半卡住，报错 Failed to connect to node2 via SSH as root。
- 先验证：
sudo su - root -c "ssh node2 date"，必须通；不通就配root的SSH key（别用grid用户的key） - TFA必须在所有节点安装且版本一致（
tfactl version输出要一样），否则-srdc会静默跳过未安装节点 - 默认输出路径是
/opt/oracle/tfa/<hostname>/repository/srdc/</hostname>，但如果你改过TFA_HOME，得确认$TFA_HOME/repository/srdc/可写 - 执行后别急着关终端——
-srdc在master节点汇总时会卡5–10分钟（尤其8节点以上集群），此时看ps -ef | grep srdc还有进程就是正常
收集完别直接传MOS：先检查3个文件
生成的SRDC包（如 srdc_node1_20260317_142233.zip）里必须含 srdc_info.txt、collection_summary.html 和 metadata.json。缺任何一个，MOS上传后状态会卡在“Processing”，最终失败。
- 用
unzip -l srdc_*.zip | grep -E "(srdc_info|summary|metadata)"快速确认 - 打开
srdc_info.txt，检查Collection Mode: SRDC和Status: SUCCESS是否存在 - 如果
collection_summary.html里显示 “0 files collected for CRS”，说明TFA没找到CRS_HOME——检查crsctl check crs是否正常，或手动加-crs
最常被忽略的是：SRDC包必须从发起节点（即你敲命令的那台）上传，不能把其他节点生成的子包单独拎出来传。包名里的hostname就是MOS校验来源的依据。
