最佳实践：针对性能问题的主动型数据收集 (文档 ID 1549179.1)_tool that helps to diagnose statements performing -CSDN博客

文档内容

适用于:

Oracle Database - Personal Edition - 版本 10.1.0.2 和更高版本
Oracle Database - Enterprise Edition - 版本 10.1.0.2 和更高版本
Oracle Database - Standard Edition - 版本 10.1.0.2 和更高版本
本文档所含信息适用于所有平台

用途

本文档介绍了一种最佳实践方法，用于确保在第一次发生问题时主动收集到足够的性能数据，从而能够有效地确定根本原因。您可以将本文档与下列文档结合使用，帮助避免问题发生，或者在问题无法避免时收集进行快速诊断所需的信息：

Document 1482811.1 Best Practices: Proactively Avoiding Database and Query Performance issues

注意：这些建议均为最佳实践，适用于技术人员所遇到的大多数情况。每个问题各不相同，并且在某些情况下，要完全实现根本原因诊断，可能需要进行其他特定诊断。预先收集每个问题的针对性信息并不一定可行，因为解决某个问题的特定诊断可能不适用于所有情况。本文档的目的是给读者提供一个坚实的起点，帮助他们收集到足够多的信息来解决大多数问题，同时针对进一步的跟踪提供及时的建议。

单击此处,可以找到一个和本文档描述内容相关的40分钟的视频.

提出问题、获取帮助并分享您的经验

您想要与其他 Oracle 客户、Oracle 员工及业内专家深入探讨吗？

单击此处，访问 My Oracle Support Community（中文），在这里您可以提出问题、获取他人的帮助并分享您的经验。

适用范围

本文档旨在为数据库用户提供关于诊断性能数据收集的主动型最佳实践的建议。

详细信息

实施总结

众所周知，要收集足够多的数据来解决复杂的性能问题是非常困难的。过去，用户在遇到问题后联系 Oracle Support 时，有可能只是被告知未收到足够多的数据，或者由于是第一次出现该问题，因而没有任何数据能够帮助他们解决问题。然后，技术支持人员会建议用户收集某些数据（随后是反复收集更多数据的过程），但在用户将这些数据发送给他们后，可能又被告知未收集到足够的数据，需要在下次问题发生时收集更多。

本文档介绍的方法，可以消除或减少不必要的数据收集以减少花费的时间和精力，从而及时解决问题。本文档中介绍的方法对数据库本身性能的影响微乎其微，有些方法（例如与 Automatic Workload Repository(AWR)相关联的方法）甚至已经集成到数据库中。

方法

我们的最佳实践方法包括：

自上而下的数据收集方法
建立多条基线
在问题发生前安装并运行正确的工具
针对不稳定的环境部署专用工具

自上而下的方法：

操作系统 (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 上的情况。

有关 OSWatcher 的下载、用户指南和使用视频等信息，请参阅以下文档。

Document 301137.1 OSWatcher User Guide (Includes: [Video])

数据库级的数据收集

几个可用于收集进行性能分析所需综合数据的工具：

AWR
在有关数据库性能问题的数据收集方面，AWR 是最全面的工具。它主要用于收集数据库指标（尽管它也可能包含一些 OS 指标）。

如果您预计不会发生性能问题且环境稳定，我们的最佳实践建议是每 60 分钟（默认）收集一次 AWR 快照。如果您担心会发生性能问题，建议您提高快照的频率。这种情况下，建议的最大快照时间间隔为 20 分钟；如果系统能够负担得起，更高频率的快照会更好。更高频率的快照可以让我们更加细致地看到在数据库上发生的情况，然后可以将这些情况与数据库性能良好时的情况进行比较。无论您选择哪种快照时间间隔，请保持这个间隔一直收集，以便能够进行报告比较。

在性能良好的时候抓取一些快照作为正常基线，以便在发生问题时进行比较，这一点非常重要。在很多时候，就算只有 AWR 数据我们也足以定位 bug，并且在一些实例中，AWR 数据会提供足够多的信息用于诊断数据库挂起及其他问题，且无需进行其他特殊的诊断，如收集 systemstate和 hanganalyze。

此外，AWR 还可用于深入探查特定的 sql 语句。如果问题发生在会话级别，则可以先获取 AWR 报告并进行分析，然后尝试进行其他 10046 或 sql 跟踪诊断。上述信息也可与 ASH 报告一起使用（见下文）。

有关 AWR 的更多信息，请参阅以下文章：

Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point
ASH
Active Session History（ASH）报告会提供非常细致的指标收集信息，因为它们会深入到会话级别。与 AWR 提供的性能数据的聚合视图相比，ASH 以 1 秒级精度提供各个数据库会话的信息。对于间歇性能问题或挂起，这非常重要。利用 ASH 数据有时足以在会话级别诊断问题，从而无需进行其他 10046 或 sql 跟踪诊断。可以根据需要通过 Automatic Workload Repository（AWR）获取 ASH 报告。

有关 Active Session History (ASH) 的更多详细信息，请参阅：

Document 243132.1 10g and above Active Session History (Ash) And Analysis Of Ash Online And Offline

Automatic Workload Repository (AWR) 和 Active Session History (ASH) 报告是 Oracle Diagnostics Pack 的两个独立组件，且必须作为单独选项获得使用许可。最佳实践建议是获取并使用该许可，从而可以访问该数据。请参阅：

Document 1490798.1 AWR Reporting - Licensing Requirements Clarification

否则，您必须使用 statspack 工具。

建立多条基线：

应根据您的业务特征，获取并存储不同时段的基线。建议的基线收集包括：

正常活动
非繁忙时间
一天中最忙的时间
月末或业务周期处理
批处理作业

拥有上述多条基线时，您将会清楚地了解系统是如何正常运行的。当发生问题时，与这些基线进行比较将有助于解决问题。如果未建立基线，要理解性能问题的本质将更加困难。如果用户在系统性能不佳时仅提供 AWR，则将更加难以分析数据库的性能；在没有比较的情况下，数据库性能好坏与否可能就会变成“主观臆测”。作为最佳实践，Oracle Support 建议创建 O/S (OSWbb) 和数据库 (AWR) 的基线。

做好准备！：在问题发生前安装并运行正确的工具

除了安装并运行 OSW 以及在指定的时间间隔收集 AWR 外，Oracle Support 还提供了一些专用工具，您应该在服务器上安装这些工具，一旦发生问题，可确保能立即派上用场。

注意：这些工具无需一直运行，但是如果事先安装好，您就可以在发生问题时快速收集信息，而不是眼见错失机会，需要等待问题重新出现

HangFG
HangFG 可以自动收集挂起诊断，用户无需知道要生成的 trace 的类型和级别。如果 HangFG 已安装，并且数据库发生了挂起，此时用户可以使用一个简单的 unix shell 命令行界面，他们可以根据自己的需要选择不同数据量的数据收集。

请参阅下列文档，获取有关 Hangfg 的下载和用户指南。

Document 362094.1 HANGFG User Guide

当前有 3 个级别可供用户选择，以启动挂起诊断信息的自动生成。这为用户提供了一定的灵活性，用户可以确保在进行挂起诊断的时候尽可能不干扰数据库（如果数据库仍处于正常运行状态）。
1. 对系统产生轻度影响。此选项收集 2 个 hanganalyze 级别 3 的 trace 文件，然后确定是否还可以在对系统产生最小影响的情况下收集 1 个 hanganalyze 级别 4 的 trace 文件。如果可以，它将收集 hanganalyze 级别 4 的 trace 文件。如果不可以，它将不收集其他 trace 文件。
2. 对系统产生中度影响（默认值）。此选项收集 1 个 hanganalyze 级别 3 的 trace 文件，然后确定是否还可以在对系统产生最小影响的情况下收集 2 个 hanganalyze 级别 4 的 trace 文件。如果可以，它将收集 2 个其他的 hanganalyze 级别 4 的 trace 文件。如果不可以，它将收集 1 个其他的 hanganalyze 级别 3 的 trace 文件。此选项还收集 1 个 systemstate 级别 266 的 trace 文件。
3. 对系统产生重度影响。此选项收集 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 性能的其他元素。
有关此工具的更多详细信息，请参阅：

Document 1366133.1 SQL Tuning Health-Check Script (SQLHC)

SQLHC 旨在允许用户确保单个 SQL 运行的环境是健康的，并尽量避免能够避免的 SQL 性能问题。运行时，它“不会在数据库上留下任何痕迹”，从而确保可以在所有系统上运行。针对一个 SQL_ID 执行时，该脚本会生成一个 HTML 报告，其中包括有关所提供的那个 SQL 语句的一组健康检查结果。
SQLTXPLAIN (SQLT)
这是一款更加复杂的工具，用于解决 SQL 性能问题（但会在数据库上留下痕迹）。SQLTXPLAIN，又称为 SQLT，是由 Oracle Support 提供的一款工具，输入一个 SQL 语句后，它会输出一组诊断文件。这些文件通常用于诊断性能不佳的 SQL 语句。SQLT 会连接到数据库，并收集执行计划、基于成本的 optimizer CBO 统计信息、schema 对象元数据、性能统计信息、配置参数和会影响正在分析的 SQL 性能的其他因素。

有关 SQLT 的更多详细信息，请参阅以下文档。

Document 215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose a SQL statement performing poorly

针对不稳定的环境部署专用工具：

大部分用户的环境是稳定的，没有任何性能问题。对于拥有不稳定环境且正遇到无法通过上述传统数据收集方法解决的挂起或遇到瞬间性能问题的用户，Oracle Support 提供了一些专用工具，以协助调试此类问题。

LTOM
LTOM 是一款可安装在客户 unix/linux 平台上的非常特别的工具。对于那些很少发生，或者发生时间很短以至于无法手工收集信息的问题，此工具可以用来自动收集需要的信息。例如，LTOM 可以监控瞬间发生的问题，并在发生问题时自动收集诊断，然后通过电子邮件通知用户，同时生成解决问题所必需的诊断 trace 文件。如果您的数据库在凌晨 2 点挂起，周围没有工作人员，LTOM 会自动检测并获取诊断，因此在您记录 SR 时 Oracle Support 就可以获取所必需的诊断 trace 文件。

有关下载和用户指南，请参阅以下文章。

Document 352363.1 LTOM - The On-Board Monitor User Guide
Procwatcher
Procwatcher 工具用于按时间间隔检查和监控 Oracle 数据库和/或集群进程。该工具会使用 Oracle 工具（如 oradebug short_stack）和/或 OS 调试程序（如 pstack、gdb、dbx 或 ladebug）收集堆栈 trace 文件，如果指定的话还会收集 SQL 数据。

有关详细信息，请参阅以下文章：

Document 459694.1 Procwatcher: Script to Monitor and Examine Oracle DB and Clusterware Processes