操作系统 (OS) 级的数据收集。
只有当 Oracle 所在的服务器以最佳状态运行时，Oracle 才能以最佳状态运行。因此，当您开始在服务器级别进行数据收集时，最好使用 OSWatcher 来捕获操作系统指标，从而可以监视并调整服务器性能。
OSWatcher
OSWatcher(OSW) 包含一个内置的分析器，通过该分析器，可以对已收集的数据进行自动分析，进而主动查找 CPU、内存、IO 和网络问题。建议所有用户安装并运行 OSWbb，因为对于查找 OS 问题，OSWbb 的作用非常大，且几乎没有开销。
在默认情况下，一旦安装并运行 OSWatcher，它将提供对最近 48 个小时的 OS 数据进行“回看”功能。因此，如果在凌晨 2 点发生了节点驱逐，Oracle Support 将能够从 OSWatcher 日志中看到当时在 OS 上发生的情况。在 OSWatcher Black Box 之前，没有办法回看在失去服务或出现严重性能问题的时候 OS 上可能发生的事情，Oracle 也无法了解 OS 上的情况。
数据库级的数据收集
AWR
在有关数据库性能问题的数据收集方面，AWR 是最全面的工具。它主要用于收集数据库指标（尽管它也可能包含一些 OS 指标）。
如果您预计不会发生性能问题且环境稳定，我们的最佳实践建议是每 60 分钟（默认）收集一次 AWR 快照。如果您担心会发生性能问题，建议您提高快照的频率。这种情况下，建议的最大快照时间间隔为 20 分钟；如果系统能够负担得起，更高频率的快照会更好。更高频率的快照可以让我们更加细致地看到在数据库上发生的情况，然后可以将这些情况与数据库性能良好时的情况进行比较。无论您选择哪种快照时间间隔，请保持这个间隔一直收集，以便能够进行报告比较。
在性能良好的时候抓取一些快照作为正常基线，以便在发生问题时进行比较，这一点非常重要。在很多时候，就算只有 AWR 数据我们也足以定位 bug，并且在一些实例中，AWR 数据会提供足够多的信息用于诊断数据库挂起及其他问题，且无需进行其他特殊的诊断，如收集 systemstate和 hanganalyze。
ASH
Active Session History（ASH）报告会提供非常细致的指标收集信息，因为它们会深入到会话级别。与 AWR 提供的性能数据的聚合视图相比，ASH 以 1 秒级精度提供各个数据库会话的信息。对于间歇性能问题或挂起，这非常重要。利用 ASH 数据有时足以在会话级别诊断问题，从而无需进行其他 10046 或 sql 跟踪诊断。可以根据需要通过 Automatic Workload Repository（AWR） 获取 ASH 报告。
建立多条基线：
应根据业务特征，获取并存储不同时段的基线。建议的基线收集包括：
- 正常活动
- 非繁忙时间
- 一天中最忙的时间
- 月末或业务周期处理
- 批处理作业
拥有上述多条基线时，会清楚地了解系统是如何正常运行的。当发生问题时，与这些基线进行比较将有助于解决问题。如果未建立基线，要理解性能问题的本质将更加困难。如果用户在系统性能不佳时仅提供 AWR，则将更加难以分析数据库的性能；在没有比较的情况下，数据库性能好坏与否可能就会变成“主观臆测”。
针对不稳定的环境部署专用工具：
大部分用户的环境是稳定的，没有任何性能问题。对于拥有不稳定环境且正遇到无法通过上述传统数据收集方法解决的挂起或遇到瞬间性能问题的用户，Oracle Support 提供了一些专用工具，以协助调试此类问题。
LTOM
LTOM 是一款可安装在客户 unix/linux 平台上的非常特别的工具。对于那些很少发生，或者发生时间很短以至于无法手工收集信息的问题，此工具可以用来自动收集需要的信息。例如，LTOM 可以监控瞬间发生的问题，并在发生问题时自动收集诊断，然后通过电子邮件通知用户，同时生成解决问题所必需的诊断 trace 文件。如果您的数据库在凌晨 2 点挂起，周围没有工作人员，LTOM 会自动检测并获取诊断，因此在您记录 SR 时 Oracle Support 就可以获取所必需的诊断 trace 文件。
Procwatcher
Procwatcher 工具用于按时间间隔检查和监控 Oracle 数据库和/或集群进程。该工具会使用 Oracle 工具（如 oradebug short_stack）和/或 OS 调试程序（如 pstack、gdb、dbx 或 ladebug）收集堆栈 trace 文件，如果指定的话还会收集 SQL 数据。
升级前要收集的信息
升级可以视为一种您知道某些东西将要发生变化的特殊情况，特别是数据库的版本变化。由于版本变化可能会包含新的功能以及可能会改变某些查询性能的缺陷修正，因此有必要在升级前收集基线信息，从而能够在升级后进行比较。为进行此操作，我们建议建立以下基线：
AWR baselines
与前面建议的标准基线类似，获取关键基线性能操作的 AWR 快照，从而可以在发生问题时将其与升级后的情况进行比较。建议的基线收集包括：
- 正常活动
- 一天中最忙的时间
- 月末或业务周期处理
- 批处理作业
在问题发生前安装并运行正确的工具
HangFG
HangFG 可以自动收集挂起诊断，用户无需知道要生成的 trace 的类型和级别。如果 HangFG 已安装，并且数据库发生了挂起，此时用户可以使用一个简单的 unix shell 命令行界面，他们可以根据自己的需要选择不同数据量的数据收集。
当前有 3 个级别可供用户选择，以启动挂起诊断信息的自动生成。这为用户提供了一定的灵活性，用户可以确保在进行挂起诊断的时候尽可能不干扰数据库（如果数据库仍处于正常运行状态）。
对系统产生轻度影响。此选项收集 2 个 hanganalyze 级别 3 的 trace 文件，然后确定是否还可以在对系统产生最小影响的情况下收集 1 个 hanganalyze 级别 4 的 trace 文件。如果可以，它将收集 hanganalyze 级别 4 的 trace 文件。如果不可以，它将不收集其他 trace 文件。
对系统产生中度影响（默认值）。此选项收集 1 个 hanganalyze 级别 3 的 trace 文件，然后确定是否还可以在对系统产生最小影响的情况下收集 2 个 hanganalyze 级别 4 的 trace 文件。如果可以，它将收集 2 个其他的 hanganalyze 级别 4 的 trace 文件。如果不可以，它将收集 1 个其他的 hanganalyze 级别 3 的 trace 文件。此选项还收集 1 个 systemstate 级别 266 的 trace 文件。
对系统产生重度影响。此选项收集 2 个 hanganalyze 级别 4 的 trace 文件和 2 个 systemstate 级别 266 的 trace 文件。
SQLHC
SQL Tuning Health-Check Script 是 Oracle Server Technologies Center of Expertise 开发的一款工具。该工具，又称为 SQLHC，用于检查单个 SQL 语句运行的环境，并检查基于成本的 optimizer (CBO) 统计信息、schema 对象元数据、配置参数和可能会影响正在分析的 SQL 性能的其他元素。
SQLHC 旨在允许用户确保单个 SQL 运行的环境是健康的，并尽量避免能够避免的 SQL 性能问题。运行时，它“不会在数据库上留下任何痕迹”，从而确保可以在所有系统上运行。针对一个 SQL_ID 执行时，该脚本会生成一个 HTML 报告，其中包括有关所提供的那个 SQL 语句的一组健康检查结果。
SQLTXPLAIN
这是一款更加复杂的工具，用于解决 SQL 性能问题（但会在数据库上留下痕迹）。SQLTXPLAIN，又称为 SQLT，是由 Oracle Support 提供的一款工具，输入一个 SQL 语句后，它会输出一组诊断文件。这些文件通常用于诊断性能不佳的 SQL 语句。SQLT 会连接到数据库，并收集执行计划、基于成本的 optimizer CBO 统计信息、schema 对象元数据、性能统计信息、配置参数和会影响正在分析的 SQL 性能的其他因素。
