做了多年数据库优化与服务工作，对TFA这样的工具已经产生了依赖性，一旦客户的系统遇到问题，肯定会让客户提供一份TFA收集的信息，然后基于这些信息进行分析。大部分问题都可以从TFA采集的数据中获得答案。Oracle TFA是一个用于收集和分析跟踪和日志文件的实用程序，可以自动检测和收集与Oracle产品相关的各种诊断数据，例如跟踪、日志、AWR报告、ASH报告和、配置文件系统信息等，并将它们汇总到一个统一的位置。使用Oracle TFA，管理员可以更快地诊断和解决问题，减少系统停机时间并提高生产力。TFA可以和Oracle Support Service紧密集成，OSS/OCS/ACS等支持部门可以利用TFA的数据完成远程分析与诊断，从而降低Oracle售后服务的成本。
我是从Oracle 5.1开始使用Oracle数据库的，经历了没有任何类似TFA的时代，要帮用户分析问题，哪怕是在现场分析，也很头疼，要从各个地方去翻找各种日志和信息。后来有了TFA的前身RDA，采集变得简单了很多。TFA能够采集的数据十分丰富，包括：
- 日志文件：例如数据库、监听器、ASM、OEM等的日志文件，可以帮助诊断各种错误和问题。
- TRACE文件：例如数据库、监听器、ASM、OEM等的跟踪文件，可以帮助诊断SQL执行、锁定等问题。
- 配置文件：例如Oracle Home、数据库、监听器、ASM、OEM等的配置文件，可以帮助确认系统配置和诊断配置问题。
- 系统信息：例如操作系统、网络、存储等的系统信息，可以帮助确认系统配置和诊断系统问题。
lDump文件：例如内存Dump文件、进程Dump文件等，可以帮助诊断内存使用、进程问题等。
lAWR报告：可以帮助分析系统性能和诊断性能问题。
lASH报告：可以帮助分析系统活动和诊断系统性能问题。
l监控信息：例如AWR快照、Metric信息、OS Watcher信息等，可以帮助分析系统性能和诊断性能问题。
TFA提高了数据库服务远程分析数据的采集能力，可以让用户一次性收集到最为详细的信息，减少现场与三线支持交互的次数，提高问题分析与故障定位的效率。有经验的DBA在Mos上开SR的时候，总会第一时间就把TFA采集好，并把数据随同SR一起上传，由于减少了多个初始阶段的交互，如果这么做，解决问题的时间可以缩短好几天。
目前国产数据库的售后服务面临更大的挑战，第三方服务能力的缺失导致客户现场问题不经缓冲直接会压到数据库原厂的售后服务人员头上，而国产数据库厂商的售后服务体系远没有Oracle那么完善和强大，因此将会面临更大的压力。目前国产数据库厂商还缺乏TFA那么强大和体系化的支持工具，因此在帮助用户解决售后问题的时候缺乏标准化的流程与标准化的分析方法，导致售后服务的效率和能力受到了进一步的限制。实际上我们可以从Oracle偷师学艺，TFA就是十分重要的一项。
首先我们可以学习TFA工具的功能，开发一个数据库诊断数据自动采集工具，采集各种日志、TRACE、配置数据，以及操作系统的一些日志、硬件信息等基础信息。再辅助一些性能、等待事件、锁、数据库信息相关的数据，构建一个后端服务支持标准化分析流程中所必须的数据。通过这样的工具不但让三线运维更加便捷，也可以通过工具规范化售后服务的一些技术分析方法，形成企业级规范化的售后服务技术分析体系。
其次我们需要关注一下OSW这个工具，OSW是Oracle采集操作系统各种信息的利器。以前我们服务的客户都会建议他们安装OSW。数据库的问题有很大一部分是和OS相关的，OSW的数据可以帮助我们厘清问题与OS还是DB有关。从Oracle 11.2.0.4开始，OSW已经成为了Oracle数据库标准安装的一部分，12C中，OSWatcher Black Box（oswbb）的引入使得OSW与Oracle数据库集成的更为紧密。国产数据库的问题很多都是OS问题引发的，因此对OS的分析更为重要。我想国产数据库也应该内置安装一套OS数据库监控的工具。因为知识产权的问题，国产数据库不可能内置安装OSW，也有些国产数据库厂商建议用户安装一个nmon之类的OS监控工具。以我这些年做数据库服务的经验来看，nmon虽然能够生成漂亮的图表，但是如果是做问题的根因定位，其数据采集的粒度和丰富程度，都远不如OSW。目前也有很多监控OS的开源工具，利用开源协议比较友好的开源工具，学习OSW采的数据内容，搞一套OS采集工具，集成到数据库产品中，应该会对售后服务有很大的帮助。
