Oracle故障日志采集“神助攻”—TFA工具详解

简介:
\


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


设想一下,如果数据库发生了一次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的工作方式:



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

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

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

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

  5. 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系统管理。

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


本文来自云栖社区合作伙伴"DBAplus",原文发布时间:2016-01-04

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
7月前
|
监控 Kubernetes Go
日志采集效能跃迁:iLogtail 到 LoongCollector 的全面升级
LoongCollector 在日志场景中实现了全面的重磅升级,从功能、性能、稳定性等各个方面均进行了深度优化和提升,本文我们将对 LoongCollector 的升级进行详细介绍。
602 86
|
5月前
|
数据采集 存储 大数据
大数据之路:阿里巴巴大数据实践——日志采集与数据同步
本资料全面介绍大数据处理技术架构,涵盖数据采集、同步、计算与服务全流程。内容包括Web/App端日志采集方案、数据同步工具DataX与TimeTunnel、离线与实时数仓架构、OneData方法论及元数据管理等核心内容,适用于构建企业级数据平台体系。
|
存储 运维 开发工具
警惕日志采集失败的 6 大经典雷区:从本地管理反模式到 LoongCollector 标准实践
本文探讨了日志管理中的常见反模式及其潜在问题,强调科学的日志管理策略对系统可观测性的重要性。文中分析了6种反模式:copy truncate轮转导致的日志丢失或重复、NAS/OSS存储引发的采集不一致、多进程写入造成的日志混乱、创建文件空洞释放空间的风险、频繁覆盖写带来的数据完整性问题,以及使用vim编辑日志文件导致的重复采集。针对这些问题,文章提供了最佳实践建议,如使用create模式轮转日志、本地磁盘存储、单线程追加写入等方法,以降低日志采集风险,提升系统可靠性。最后总结指出,遵循这些实践可显著提高故障排查效率和系统性能。
1105 21
|
6月前
|
存储 运维 开发工具
警惕日志采集失败的 6 大经典雷区:从本地管理反模式到 LoongCollector 标准实践
本文总结了日志管理中的六大反模式及优化建议,涵盖日志轮转、存储选择、并发写入等常见问题,帮助提升日志采集的完整性与系统可观测性,适用于运维及开发人员优化日志管理策略。
243 5
|
2月前
|
数据采集 缓存 大数据
【赵渝强老师】大数据日志采集引擎Flume
Apache Flume 是一个分布式、可靠的数据采集系统,支持从多种数据源收集日志信息,并传输至指定目的地。其核心架构由Source、Channel、Sink三组件构成,通过Event封装数据,保障高效与可靠传输。
229 1
|
3月前
|
存储 Kubernetes 监控
Kubernetes日志管理:使用Loki进行日志采集
通过以上步骤,在Kubernetes环境下利用LoKi进行有效率且易于管理地logs采集变成可能。此外,在实施过程中需要注意版本兼容性问题,并跟进社区最新动态以获取功能更新或安全补丁信息。
286 16
|
7月前
|
存储 缓存 Apache
StarRocks+Paimon 落地阿里日志采集:万亿级实时数据秒级查询
本文介绍了阿里集团A+流量分析平台的日志查询优化方案,针对万亿级日志数据的写入与查询挑战,提出基于Flink、Paimon和StarRocks的技术架构。通过Paimon存储日志数据,结合StarRocks高效计算能力,实现秒级查询性能。具体包括分桶表设计、数据缓存优化及文件大小控制等措施,解决高并发、大数据量下的查询效率问题。最终,日志查询耗时从分钟级降至秒级,显著提升业务响应速度,并为未来更低存储成本、更高性能及更多业务场景覆盖奠定基础。
|
4月前
|
存储 缓存 Apache
StarRocks+Paimon 落地阿里日志采集:万亿级实时数据秒级查询
A+流量分析平台是阿里集团统一的全域流量数据分析平台,致力于通过埋点、采集、计算构建流量数据闭环,助力业务提升流量转化。面对万亿级日志数据带来的写入与查询挑战,平台采用Flink+Paimon+StarRocks技术方案,实现高吞吐写入与秒级查询,优化存储成本与扩展性,提升日志分析效率。
542 1
|
8月前
|
监控 算法 测试技术
突破极限: 高负载场景下的单机300M多行正则日志采集不是梦
在当今数字化时代,日志数据已成为企业 IT 运营和业务分析的关键资源。然而,随着业务规模的扩大和系统复杂度的提升,日志数据的体量呈现爆发式增长,给日志采集和处理系统带来了巨大挑战。
576 99

热门文章

最新文章

推荐镜像

更多