一文彻底搞懂Oracle数据库出现性能问题时，需要主动收集哪些信息？-51CTO.COM

问题

当Oracle数据库出现复杂性能问题时，需要Oracle技术人员提供技术支持，但收集足够的数据来解决复杂的性能问题是很难实现的。

从历史上看，用户会遇到性能问题，联系Oracle支持人员，结果却被告知当时收集的数据不足，或者不存在任何数据，无法在问题首次出现后让支持人员解决问题。然后建议用户在事后打开额外的数据收集（然后是收集更多数据的迭代过程），将其发送给支持部门，但再次被告知收集的数据不足，需要进一步中断和收集更多数据。

本文档描述了一种消除或减少不必要的数据收集的方法，以减少所花费的时间和精力，及时解决问题。所有概述的方法对数据库本身的性能影响最小，有些方法（如与自动工作负载存储库（AWR）相关的方法）已经集成。

简介

Oracle主动收集

目的

本文档描述了一种最佳实践方法，以确保在问题首次出现时主动收集足够的性能数据，从而能够有效地确定根本原因。它可以与以下文档一起使用，以避免问题，然后如果不可避免，收集快速诊断所需的信息：

注意

这些建议是适用于支持遇到的主要场景的最佳实践。

每个问题都是不同的，在某些情况下可能需要特定的额外诊断来完全实现根本原因诊断。

为每个问题预先收集这些有针对性的信息不一定可行，因为解决一个特定问题所需的特定诊断可能并不适用于所有情况。目标是提供一个坚实的起点，收集足够的信息来解决大多数问题，或为进一步追踪提供及时的建议。

方法论

我们的最佳实践方法包括以下内容：

1.自上而下的数据收集方法
2.建立多个基线
3.在问题发生之前，已经安装并运行了正确的工具
4.为不稳定环境部署专用工具

一、自上而下的方法

1.操作系统（O/S）级别的数据收集

Oracle只有在其运行的服务器也达到最佳性能时才能达到最佳性能。因此，通过使用OSWatcher捕获操作系统指标，在服务器级别开始数据收集是明智的，这样可以监控和调整服务器的性能。

1.1 OSWatcher

OSWatcher（OSW）包含一个内置的分析器，可以自动分析收集到的数据，主动查找cpu、内存、io和网络问题。建议所有用户安装并运行OSW，因为它对于查看操作系统上的问题非常有价值，而且开销很小。

一旦安装并运行，OSWatcher将默认提供48小时的操作系统“回顾”数据。因此，例如，如果节点驱逐发生在凌晨2点，Oracle支持人员将能够从OSWatcher日志中查看在此期间操作系统上发生了什么。在OSWatcher出现之前，没有办法回顾操作系统在停机或严重性能问题期间可能发生的情况，Oracle也不知道操作系统上发生了什么。

有关OSWatcher上的下载、用户指南和使用视频，请参阅以下内容

Refer to the following for download, user guide and usage videos on OSWatcher
Document 301137.1 OSWatcher
Document 2942344.1 OSWatcher Video Series

其他相关文章：

Document 1531223.1 OSWatcher User Guide
Document 461053.1 OSWatcher Analyzer User Guide

OSWatcher介绍

图片

OSWatcher（oswbb）是一个可下载的实用程序，用于从操作系统中捕获性能指标。OSWatcher的使用符合Oracle的标准许可条款，不需要额外的许可证。当您安装并运行oswbb作为性能诊断数据收集最佳实践的一部分时，您可以通过支持和开发来帮助更快地解决SR问题。oswbb由两个独立的组件组成：

1.oswbb：一个收集和存储数据的unixshell脚本数据收集器。
2.oswbba：一个java实用程序，它将自动分析数据，提供建议，并生成图形和html文档

这两个组件都包含在一个可下载的tar文件中。

请勿将此实用程序与OSWatcher的Exadata版本混淆。

下载方式：

下载链接在 301137.1 文档里，可以单独下载，也可以作为TFA/AHF工具的一部分进行安装。

图片

最佳实践:

作为最佳实践，支持人员建议所有Oracle用户在运行Oracle的服务器上部署OSWatcher。OSWatcher应被视为对可能存在的任何其他数据收集的补充或补充。

主要原因是，如果支持人员必须向开发人员提交错误，开发人员很可能会坚持提供OSWatcher数据。否则，在安装OSWatcher并再次出现问题之前，该错误可能无法继续。此外，支持分析师熟悉并接受过了解基本操作系统诊断实用程序（如vmstat、iostat、top等）输出的培训。支持分析师可能不熟悉您现有的其他类型的自定义或特定于操作系统的数据收集。最后，支持人员能够使用内部工具分析OSWatcher数据，从而避免了手动检查数十个文件的耗时任务。这将大大缩短您的解决时间。

支持人员建议您运行OSWatcher，默认快照间隔为30秒，默认保留期为48小时。以大于60秒的速率拍摄不太频繁的快照或采样对于诊断性能问题没有帮助。

例如:

./startOSWbb.sh 30 48 None /usr/app/archive

监控结果，示例如下:

I/O

图片

进程

图片

内存

图片

2.数据库级别的数据收集

Data collection at Database level

2.1 AWR

自动工作量资料档案库

Automatic Workload Repository

AWR是围绕数据库性能问题收集数据的最全面的实用程序。它主要用于收集数据库周围的指标（尽管它也包括一些操作系统指标）。

如果您预计不会出现性能问题，并且处于稳定的环境中，我们的最佳实践建议是以默认的60分钟速率启用AWR快照。如果您担心出现性能问题，建议更频繁地进行快照。在这种情况下，我们建议以最长20分钟的间隔进行快照；如果你能负担得起，比这更频繁的快照总是更好。更频繁的快照使我们能够以更高的粒度查看数据库上发生的事情，并可用于比较数据库性能良好的时间。无论您选择什么快照间隔，都要尽量坚持下去，以方便报告之间的比较。

捕获一些快照非常重要，这些快照可以被视为正常性能的良好基线，可以在以后与问题发生时进行比较。很多时候，仅仅拥有AWR数据就可以为错误识别提供足够的信息，在某些情况下，还可以提供足够的数据来诊断数据库挂起和其他问题，而不需要进行特殊的额外诊断，如systemstate 转储和 hanganalyze跟踪。

AWR还可以用于深入查看特定的sql语句。如果问题在会话级别，则可以在尝试进行额外的10046或sql trace诊断之前获取并分析AWR报告。此信息也可与ASH报告结合使用（见下文）。

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

Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point
How to Generate an AWR Report and Create Baselines (Doc ID 748642.1)
FAQ: Automatic Workload Repository (AWR) Reports (Doc ID 1599440.1)
NOTE:94224.1 - FAQ- Statspack Complete Reference
NOTE:1301503.1 - Troubleshooting: Missing Automatic Workload Repository (AWR) Snapshots and Other Collection Issues
NOTE:782974.1 - How to Recreate the Automatic Workload Repository (AWR)?
NOTE:1399365.1 - Troubleshooting Issues with SYSAUX Space Usage
NOTE:329984.1 - Usage and Storage Management of SYSAUX tablespace occupants SM/AWR, SM/ADVISOR, SM/OPTSTAT and SM/OTHER
NOTE:754639.1 - How to Read Buffer Cache Advisory Section in AWR and Statspack Reports.
NOTE:560204.1 - MMON Trace Shows: "*** KEWRAFC: Flush slave failed, AWR Enqueue Timeout"
NOTE:1490798.1 - AWR Reporting - Licensing Requirements Clarification
NOTE:1359094.1 - How to Use AWR Reports to Diagnose Database Performance Issues
NOTE:748642.1 - How to Generate an AWR Report and Create Baselines
NOTE:276103.1 - Performance Tuning Using Advisors and Manageability Features: AWR, ASH, ADDM and SQL Tuning Advisor
NOTE:459887.1 - ORA-13516 AWR Operation failed: SWRF Schema not initialized ORA-06512 SYS.DBMS_WORKLOAD_REPOSITORY
NOTE:733655.1 - AWR Diagnostic Collection Script
NOTE:287679.1 - How to Address Issues Where AWR Data Uses Significant Space in the SYSAUX Tablespace
NOTE:296765.1 - Solutions for possible AWR Library Cache Latch Contention Issues in Oracle 10g
NOTE:786554.1 - How to Read PGA Memory Advisory Section in AWR and Statspack Reports to Tune PGA_AGGREGATE_TARGET
NOTE:1357637.1 - How to Control the Number of SQL Statements and other information displayed in AWR Report

AWR报告可以通过运行各种SQL脚本来生成，以满足各种要求。每份报告都有HTML或TXT格式：

awrrpt.sql
显示一系列快照ID的各种统计信息。
awrrpti.sql
显示指定数据库和实例上快照ID范围的统计信息。
awrsqrpt.sql
显示一系列快照ID的特定SQL语句的统计信息。运行此报告以检查或调试特定SQL语句的性能。
awrsqrpi.sql
显示指定数据库和实例上快照ID范围的特定SQL语句的统计信息。
awrddrpt.sql
比较两个选定时间段之间的详细性能属性和配置设置。
awrddrpi.sql
比较特定数据库和实例上两个选定时间段之间的详细性能属性和配置设置。

例如:

图片

2.2 ASH

Active Session History

活动会话历史（ASH）报告在深入到会话级别时提供了非常精细的度量收集。与AWR提供的性能数据的汇总视图相比，ASH为每个单独的数据库会话提供1秒级精度的信息。这对于间歇性性能问题或挂起非常重要。利用ASH数据有时足以在会话级别诊断问题，从而避免进行额外的10046或sql trace诊断。ASH报告可以根据需要通过高级工作负载存储库（AWR）获得。

二、建立多个基线

根据您的业务概况，应获取基线捕获并存储不同的时间段。

建议的基线收集将是：

1.正常活动

2.非繁忙时间

3.一天中最繁忙的时间

4.月末或业务周期处理

5.批量处理。

有了这些多个基线，你就能很好地了解系统的正常运行情况。

当出现问题时，与这些基线进行比较将有助于解决问题。

未能建立基线会使理解性能问题的性质变得更加困难。

如果用户只在系统性能不佳时提供AWR，那么分析数据库的性能就困难得多；

与数据库性能相比，没有什么可以成为一种“主观观察”。

作为最佳实践，支持人员建议为O/S（OSW）和数据库（AWR）创建基线。

三、提前安装正确的工具

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

除了安装和运行OSW以及以指定的时间间隔收集AWR外，Oracle支持还提供了一些专门的工具，这些工具应该安装在您的服务器上，并在出现问题时随时可用。

注意：这些工具不必运行，但预安装允许您在出现问题时快速收集信息，而不是错过机会并等待再次发生。

3.1 HangFG

HangFG允许收集挂起诊断，而用户不必知道要采取何种类型和级别的跟踪。

如果安装了HangFG，并且发生挂起，则用户有一个简单的unix shell命令行界面，允许他们选择他们能够承受的数据收集的“繁重”程度。

有关Hangfg的下载和用户指南，请参阅以下内容。

Document 362094.1 HANGFG User Guide
Document 1482811.1 Best Practices: Proactively Avoiding Database and Query Performance Issues
Document 1477599.1 Best Practices Around Data Collection For Performance Issues

目前，用户可以选择3个级别来启动挂起诊断的自动生成。

这为用户提供了在尽可能不引人注目的情况下进行挂起诊断的灵活性（如果数据库仍处于功能状态）。

1.光对系统的影响。

此选项收集2个hanganalyze级别3跟踪，然后确定它是否也可以在对系统影响最小的情况下收集1个hanganalyse级别4跟踪。如果是这样，它将收集hanganalyze 4级跟踪。如果没有，则不会收集其他跟踪文件。

2.对系统影响中等（默认值）。

此选项收集1个hanganalyze级别3跟踪，然后确定它是否也可以在对系统影响最小的情况下收集2个hanganalyse级别4跟踪。如果是这样，它会收集另外2个hanganalyze级别4的痕迹。如果没有，它将收集额外的hanganalyze 3级跟踪。此选项还收集1个系统状态级别266跟踪。

3.对系统影响较大。

此选项收集2个hanganalyze级别4跟踪和2个系统状态级别266跟踪。

运行HangFG：

./hangfg.sh <ARG1>

参数如下:

3.2 SQLHC

SQL Tuning Health-Check

SQL调优健康检查脚本是由Oracle Server技术专家中心开发的一种工具。

该工具也称为SQLHC，用于检查单个SQL语句运行的环境，检查基于成本的优化器（CBO）统计数据、模式对象元数据、配置参数和其他可能影响所分析SQL性能的元素。

SQLHC的目的是允许用户确保单个SQL运行的环境是健全的，并希望避免SQL性能问题产生可避免的问题。

它做到了这一点，同时“没有数据库足迹”，确保它可以在所有系统上运行。

当对一个SQL-ID执行时，此脚本会生成一个HTML报告，其中包含围绕所提供的一个SQL语句进行的一组健康检查的结果。

使用示例:

sqlplus / as sysdba
SQL> START sqlhc.sql "T" djkbyr8vkc64h

图片

3.3 SQLTXPLAIN (SQLT)

存在一种更复杂的工具来解决SQL性能问题（但这需要数据库上的足迹）。

SQLTXPLAIN，也称为SQLT，是由支持提供的工具，输入一条SQL语句并输出一组诊断文件。

这些文件通常用于诊断性能不佳的SQL语句。

SQLT连接到数据库并收集执行计划、基于成本的Optimizer CBO统计数据、模式对象元数据、性能统计数据、配置参数以及影响所分析SQL性能的类似元素。

下载地址:

SQLT收集的文件

以下是SQLT收集的文件类型的带注释列表（在本例中使用XECUTE方法）：

图片

四、为不稳定的环境部署专用工具

大多数用户在稳定的环境中运行时没有任何性能问题。

对于那些没有稳定环境并且遇到挂起或瞬态性能问题的用户，这些问题无法通过上述传统数据收集来解决，Oracle支持部门有一些专门的工具来帮助调试这些问题。

4.1 Procwatcher

Procwatcher是一个定期检查和监视Oracle数据库和/或集群软件进程的工具。该工具将使用Oracle工具（如oradebug short_stack）和/或操作系统调试器（如pstack、gdb、dbx或ladebug）收集这些进程的堆栈跟踪，并在指定的情况下收集SQL数据。

详见以下文章：

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

当前打不开了

五:升级前要收集什么

升级可以被视为一种特殊情况，在这种情况下，你知道有些事情会发生变化；

特别是数据库的版本。由于版本更改可能包含新功能和对可能改变某些查询性能的缺陷的修复，因此在升级之前收集基线信息是有意义的，这样您就可以在升级后进行比较。

为此，我们建议：

AWR基线

以与之前建议的标准基线类似的方式，对关键基线性能操作进行AWR快照，以便在出现问题时将其与升级后的情况进行比较。

建议的基线收集将是：

1.正常活动
2.一天中最繁忙的时间
3.月末或业务周期处理
4.批量处理

SQL计划管理基线

SQL Plan management Baselines

SQL计划管理可用于跨版本保持SQL性能。

如果希望在升级前后保持SQL的性能，请创建要保留的SQL语句的基线。

我们建议至少对应用程序中的关键SQL语句这样做。

将它们传输到新系统并启用它们。

六、主动最佳实践清单

主动最佳实践清单

1.在安装了Oracle数据库的每个节点上安装并运行OSWatcher。
每天运行OSWatcher分析器，查找服务器上的性能问题。
2.获取诊断包许可证
3.配置AWR快照间隔，并验证AWR快照是否按预期间隔进行
4.为O/S（使用OSW）和数据库（使用AWR）建立多个基线。
5.如果您遇到数据库挂起，请下载Hangfg并准备好运行
6.安装SQLHC并按预期的时间间隔运行
7.如果需要在数据库上安装SQLT，请下载SQLT并做好准备
8.如果您在不稳定的环境中运行，并且使用上述工具无法解决问题，请考虑下载并安装LTOM

七、记录服务请求

如果需要SR，请参阅以下内容以了解包括哪些内容的详细信息：

A.数据库范围内的问题

1.一般数据库性能问题

数据库运行速度比正常情况慢，问题似乎不是由于一个SQL语句或会话造成的。

1.1一些好问题

(1).问题是否一致，或者它是否只在一天中的某些时间或在某些负载下运行缓慢（例如，当它变慢时，您可能有一个sqlloader会话在运行？）如果它只在某些时间运行，那么请调查该时间的具体情况（可能是热备份、计划作业、批处理运行）。

(2).发生了什么变化？

(3).大多数性能问题都是由重大变化引起的（与负载逐渐增加引起的变化相反）。

(4).您是否升级了Oracle版本，最近是否应用了补丁？

(5).您是否更改了init.ora参数？

(6).负载是否大幅增加（例如新应用程序或正在实施的应用程序的一部分）？

(7).咨询您的UNIX和网络管理员，以确定最近是否有更改。

(8).如果你能够恢复业绩（但因此无法满足你的短期业务需求），那么你做了什么来影响它？

(9).您运行的是当前版本的最新补丁集吗？

(10).查看patchset发布说明，了解最新可用的patchset。它将指示哪些BUG被固定在其中。

(11).对照你看到的问题检查这份清单。也许你正在打其中一个。确保补丁已正确应用。

上述信息对于解决问题至关重要，因此在记录SR时，请尽量描述可能对我们有所帮助的更改类型或相关信息。

1.2 你可以做些什么来帮助确定根本原因?

如果可以，请撤消您所做的任何更改，看看问题是否仍然存在。

如果你做了不止一个更改，那么就逐一撤销它们，直到问题消失。

即使问题没有消失，这仍然是一个很好的信息，因为它证明了问题与更改无关。

1.3我们需要什么证据？

1.提供一份涵盖性能问题期间的AWR报告

2.提供性能正常且工作量相似的一段时间内的AWR（最好是几天前的同一时间）

下载:

参考:

Best Practices: Proactive Data Collection for Performance Issues (Doc ID 1477599.1)