收集日志信息是否是一个“高消耗”的体力活？很多情况下都是。

设想一下，如果数据库发生了一次hang的故障，而这套数据库有8个节点，我们可能需要收集rdbms、ASM、grid、OS，osw等等的日志信息，这项工作就是一个噩梦。即使在常见的两节点RAC环境中，恐怕也需要花费一小段的时间，而且可能还得不断进行后续的补充日志收集工作。

不熟悉环境，平台差异，需要筛选收集故障时间点的特定日志信息，数据库存在较多的节点，在需要收集日志的环境中存在文件管控等等很多的问题，都可能影响我们收集日志信息的速度和准确度，进而对问题分析定位的进度造成影响。

所以我们就有一个非常现实的问题，如何减少日志收集所消耗的时间并提高准确度，将更多的时间用于问题分析？

其实，Oracle官方已经提供了解决方案—TFA(Trace File Analyzer Collector)，这个工具能帮助我们真正实现一条命令完成日志收集。

官方列出TFA支持的平台：

Intel Linux (Enterprise Linux, RedHat Linux, SUSE Linux)

Linux on System Z

Linux Itanium

Oracle Solaris SPARC

Oracle Solaris x86-64

AIX

HPUX Itanium

HPUX PA-RISC

所有平台都需要bash shell 3.2 以上版本及JRE 1.5以上版本支持。

TFA工具理论上提供所有数据库版本的支持，同时提供对RAC和非RAC数据库的支持。但是，从当前所见的文档中，未见提及10.2.0.4之前的版本。

TFA工具最早在11.2.0.4版本中随grid软件默认安装，默认安装路径为grid的home目录。11.2.0.4之前版本的安装包中并未包含TFA工具，需要手工安装。

Oracle官方列出的详细支持及安装情况如下：

TFA更新的速度非常快，11.2.0.4版本于2013年8月发布，自带的TFA工具版本为2.5.1.5。目前（2015年10月）最新版本为12.1.2.5.2，我们可以从帮助菜单中看出两个版本间的巨大差别：

2.5.1.5版本帮助菜单：

12.1.2.5.2版本帮助菜单：

可以看到，12.1.2.5.2版本相比2.5.1.5版本加入了大量的功能。

Oracle对TFA的支持力度也在不断增大，甚至已经将TFA的更新包含在了PSU中。以11.2.0.4版本为例，GI PSU Fixed List中我们可以找到以下信息：

即从11.2.0.4.5开始，GI PSU中都包含有TFA的版本更新。在安装GI PSU的过程中TFA将自动进行安装。

从一张Oracle官方提供的TFA工作流程图上，我们可以清楚的看到TFA的工作方式：

1. DBA发出diagcollect命令，启动TFA日志收集进程。

2. 本地TFA发送收集请求至其他节点的TFA，在其他节点上开始日志收集工作。

3. 本地TFA也同时开始进行日志收集工作。

4. 所有涉及节点的TFA日志都归档至发起diagcollect命令的"master"节点。

5. DBA提取已归档的TFA日志信息，进行分析或提交SR进行处理

   
   

整个过程中，DBA只需要执行一条命令，然后提取已归档的TFA日志。

以11.2.0.4版本RAC和12.1.2.5.2版本TFA环境为例：

首先，我们来看最简单、通用的一个收集命令：

此命令将收集指定时间段rdbms、ASM、grid、OS的各类型日志，如alert日志、trace文件、clusterware各组件的日志、listener日志、操作系统日志。执行过程中，对alert日志、listener日志等连续性的日志处理也比较智能，能够截取指定时段的日志，而不会将整个日志文件copy。如果部署有osw工具，还会自动收集osw的日志。

如果需要指定日志收集范围，比如仅收集数据库的相关日志，可以使用tfactl diagcollect -database命令。更多的使用方法可以参考tfactl diagcollect -help输出。

当前最新版本（12.1.2.5.2）的TFA也能够对AWR报告进行收集，命令示例如下：

但是在实际应用中发现，TFA收集AWR报告的功能还不够完善。

对于 -database 参数，帮助菜单的说明为：

-database  Collect database logs from databases specified

目前，使用 -awrhtml 参数需要配合 -database 参数一同使用，但 -database 参数与 -awrhtml 参数配合使用的情况下，并不仅仅为指示数据库名称的作用，依然会出现收集数据库alert日志及trace文件的情况。即执行以上命令，将收集指定时间段的AWR报告，同时也会收集数据库alert日志和trace文件。

TFA也带有自动收集的功能，可以对一些预定错误进行自动收集。预定的错误及收集规则可以参阅《Trace File Analyzer Collector User Guide》的Appendix B. Scan Events部分。该功能默认为关闭状态，可以使用以下命令手工启用：

tfactl set autodiagcollect=ON

此功能建议在测试环境中验证后再在生产环境中进行使用。

TFA也能够承担一定的日志分析功能，能够实现一条命令自动对DB&ASM&CRS的alert日志、操作系统命令及部分osw日志进行分析，虽然与它的日志收集功能相比还不够强大。一个简单通用的分析命令：

tfactl analyze -since 7d

这条命令将分析查找所有（包括DB/ASM/CRS/ACFS/OS/OSW/OSWSLABINFO）日志7天内ERROR级别的错误信息并提取。

《Trace File Analyzer Collector User Guide》所列出的ERROR级别信息如下：

也可以使用如下命令搜索自定义字符串：

TFA工具默认仅对root用户和grid用户授予使用权限，如果使用oracle用户执行tfactl diagcollect命令将收到报错：

User oracle does not have keys to run TFA. Please check with TFA Admin(root)

建议同样授予oracle用户使用TFA的权限，方便日常使用。root用户使用以下命令可以将oracle用户加入授权用户列表：

tfactl access add -user oracle

如果存在对收集日志的空间管理需求，可以使用tfactl set命令进行设置。当前设置情况可以通过

tfactl print config

命令进行输出，输出示例如下：

有关TFA使用和设置的更多信息可以参阅tfactl -h输出及《Trace File Analyzer Collector User Guide》文档。

MOS上较少见到TFA运行过程中对DB或GI造成影响的描述，主要为以下两个问题：

如果在Linux平台下遇到RAC节点启动hang的问题并且环境中安装有TFA，可以根据文档1983567.1的说明修改oracle-tfa.conf文件。文档 1668630.1所提及的问题在11.2.0.4.3以上PSU中已修复，如果安装的PSU版本为11.2.0.4.3以上版本，可以忽略此问题。

作者介绍：杨德胜

• 新炬网络公司高级技术专家，4年Oracle数据库运维管理经验。

• 精通oracle 10g、11g数据库管理和Linux/Unix系统管理。

• 擅长进行数据库及集群的故障诊断与系统优化，并持续专注于故障诊断技术的研究与实践。