Oracle故障日志采集“神助攻”—TFA工具详解
转载声明：本文为DBA+社群原创文章，转载必须连同本订阅号二维码全文转载，并注明作者名字及来源：DBA+社群（dbaplus）。
收集日志信息是否是一个“高消耗”的体力活？很多情况下都是。
设想一下，如果数据库发生了一次hang的故障，而这套数据库有8个节点，我们可能需要收集rdbms、ASM、grid、OS，osw等等的日志信息，这项工作就是一个噩梦。即使在常见的两节点RAC环境中，恐怕也需要花费一小段的时间，而且可能还得不断进行后续的补充日志收集工作。
不熟悉环境，平台差异，需要筛选收集故障时间点的特定日志信息，数据库存在较多的节点，在需要收集日志的环境中存在文件管控等等很多的问题，都可能影响我们收集日志信息的速度和准确度，进而对问题分析定位的进度造成影响。
所以我们就有一个非常现实的问题，如何减少日志收集所消耗的时间并提高准确度，将更多的时间用于问题分析？
其实，Oracle官方已经提供了解决方案—TFA(Trace File Analyzer Collector)，这个工具能帮助我们真正实现一条命令完成日志收集。
1版本以及安装
官方列出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将自动进行安装。
2TFA的工作方式
从一张Oracle官方提供的TFA工作流程图上，我们可以清楚的看到TFA的工作方式：
DBA发出diagcollect命令，启动TFA日志收集进程。
本地TFA发送收集请求至其他节点的TFA，在其他节点上开始日志收集工作。
本地TFA也同时开始进行日志收集工作。
所有涉及节点的TFA日志都归档至发起diagcollect命令的"master"节点。
DBA提取已归档的TFA日志信息，进行分析或提交SR进行处理
整个过程中，DBA只需要执行一条命令，然后提取已归档的TFA日志。
3TFA的使用
以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系统管理。
擅长进行数据库及集群的故障诊断与系统优化，并持续专注于故障诊断技术的研究与实践。
小编精心为大家挑选了近日最受欢迎的几篇热文:
回复001，看杨志洪《【职场心路】一个老DBA的自白》；
回复002，看丁俊的《【重磅干货】看了此文，Oracle SQL优化文章不必再看！》；
回复003，看胡怡文《PG，一道横跨oltp到olap的梦想之桥》；
回复004，看陈科《memcached&redis等分布式缓存的实现原理》；
回复005，看宋日杰《Oracle后台专家解决library cache锁争用的终极武器》；
回复006，看郑晓辉《存储和数据库不得不说的故事》；
回复007，看袁伟翔《揭秘Oracle数据库truncate原理》；
回复008，看杨建荣《立等可取:工具定制让Oracle优化变得更简单快捷》；
回复009，看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》；
回复010，看徐桂林《以应用为中心的企业混合云管理》。
DBA+社群是中国最大的涵盖各种架构师、数据库、中间件的微信社群！线上分享2次/周、线下沙龙1次/月，顶级峰会6次/年，直接受众10000+，间接影响50万+ITer。DBA+社群致力于搭建一个学习交流、专业人脉、跨界合作的公益平台，更多精彩请持续关注dbaplus微信订阅号！
扫码关注
DBAplus社群
超越DBA圈子，连接的不仅仅是DBA