Oracle如何使用AWR诊断性能问题

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected]

 

这篇文章为专门解释数据库性能问题的AWR信息提供指导。

请记住,为了生成报告,访问AWR视图,或者使用AWR的任何部分来诊断信息,要求要有Diagnostic Pack License。这包括生成AWR报告,ADDM报告和ASH报告,尽管是产品支持或其他代理提出的请求。

NOTE: Oracle Diagnostics Pack (and Oracle Tuning Pack) is available with Enterprise Edition ONLY. For further details of pack licensing

see:

Oracle® Database Licensing Information
12c Release 1 (12.1)
Part number E17614-08
Chapter 1 1 Oracle Database Editions
Feature Availability by Edition
http://docs.oracle.com/database/121/DBLIC/options.htm#DBLIC139

 

Best Practices

Pro-Active Problem Avoidance and Diagnostic Collection

尽管有些问题是无法预见的,在一些情况下如果早期发现有足够的迹象是可以避免的。如果一个问题已经发生了,去收集时间发生之后的信息是没用的。AWR报告是推荐的收集诊断信息的方法。建议使用的信息,其他积极的准备和诊断,参照:

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

 

解决方案

AWR是一个非常有用的诊断工具AWR,用来测定数据库潜在的性能问题。

通常当检测到一个性能问题,你可以收集AWR报告在性能表现不佳的时期。最好使用一个报告周期不超过一个小时,否则可能会丢失其他细节。

关于收集AWR报告的信息参考:

Document 1363422.1 Automatic Workload Repository (AWR) Reports – Start Point

当有问题的时候,收集AWR报告如果有提供基线可用来对比。确保基线快照持续的时间和问题持续的时间一样,方便进行对比。

注释:我们建议使用匹配的ADDM报告来初始定位主要问题。 We would also recommend using a matched ADDM report initially to give a pointer to the main issues. 第一步优化读相应的ADDM报告能节省很大一部分时间,因为它相比AWR报告直接指出主要的用户。
参照: Use of ADDM Reports along side AWR

AWR Webcast

下载AWR非常有用,特别是:

  • “通过AWR排查数据库的性能问题”

你可以下载从下面的这篇文档里:

Document 1456176.1 Oracle Database Advisor Webcast Archives

Interpretation

当寻求解释数据库性能差的原因,我们建议你先看下面的文章:

Document 1628089.1 AWR Report Interpretation Checklist for Diagnosing Database Performance Issues

这篇文章提供一些要记住的背景信息指导。

我们开始看性能问题,我们首先关心数据库在等待什么。当进程等待,因为其他因素被阻止进行活动。当减少高的等待事件能带来更大的好处,因此是一个很好的关注点。最高的等待信息提供这些信息和允许我们关注主要问题,不会浪费时间在调查未引起严重延长的区域。

  • Top 5 Timed Events

上面提到,Top等待部分是报告里最重要的部分,它量化和允许比较主要的诊断:每个会话在等待什么。下面提供一个输出例子:

Top 5 Timed Events                                         Avg %Total

~~~~~~~~~~~~~~~~~~                                        wait   Call

Event                                 Waits    Time (s)   (ms)   Time Wait Class

------------------------------ ------------ ----------- ------ ------ ----------

db file scattered read           10,152,564      81,327      8   29.6   User I/O

db file sequential read          10,327,231      75,878      7   27.6   User I/O

CPU time                                         56,207          20.5

read by other session             4,397,330      33,455      8   12.2   User I/O

PX Deq Credit: send blkd             31,398      26,576    846    9.7      Other

         -------------------------------------------------------------

前5个等待部分报告相关有许多有用的主题。它记录了等待的次数,等待的总共时间,每个事件的平均等待事件。这部分是按照占总共的时间的百分比排序的。

依靠什么在本节看到的,报表其他的部分可能需要以量化或检查发现被引用。例如,对于特定的事件的等待计数需要评估基于报告周期的持续时间以及在该时间在数据库上的用户的数目; 1000万等待10分钟比1000万等待10小时内更为显著,或者,如果10个用户共享,而不是10,000。

在上面报告的例子,差不多60%的时间是花费在I/O相关读上。

    • ‘db file scattered read ‘ 事件是全表扫描索引快速全扫描实现多块读。
    • ‘db file sequential read’ 事件是单块读和多块读I/O不可用(如索引读)。

另外20%的时间用来等待CPU时间。高CPU使用率经常是比较差性能的SQL(或者至少SQL可能占用更少的资源)过多的I/O也可能是原因,过多的CPU使用率之后。

基于此,我们调查这些等待事件是否表明什么问题。如果是,解决问题,如果不是,继续下一个等待来确定潜在的原因。

I/O相关的等待成为前面的事件有两种原因:

    • 这数据库在进行大量的读
    • 各单个读很慢

这个前5等待事件信息对我们有这些帮助:

    • 数据库是否在进行大量的读?
      这部分显示>在这个时期每个这种事件有1000万读。
      这是否是大量读取决于报告的持续时间是一小时还是一分钟。
      检查这个报告的持续时间来评估。

如果读视乎过度,那为什么这个数据库会有大量的读?
数据库读数据是因为执行了SQL语句。进一步调查参考SQL Statistics 部分.

    • 单个读很慢?
      这部分显示两个相关的事件单个等待时间<=8 ms。
      这是快还是慢取决于硬件底层I/O子系统。通常低于20ms是可以接受的。

如果I/O慢,你可以获取进一步信息从’Tablespace IO Stats ‘部分:

Tablespace

——————————

Av      Av     Av                       Av     Buffer Av Buf

Reads Reads/s Rd(ms) Blks/Rd       Writes Writes/s      Waits Wt(ms)

————– ——- —— ——- ———— ——– ———- ——

TS_TX_DATA

14,246,367     283    7.6     4.6  145,263,880    2,883  3,844,161    8.3

USER

204,834       4   10.7     1.0   17,849,021      354     15,249    9.8

UNDOTS1

19,725       0    3.0     1.0   10,064,086      200      1,964    4.9

AE_TS

4,287,567      85    5.4     6.7          932        0    465,793    3.7

TEMP

2,022,883      40    0.0     5.8      878,049       17          0    0.0

UNDOTS3

1,310,493      26    4.6     1.0      941,675       19         43    0.0

TS_TX_IDX

1,884,478      37    7.3     1.0       23,695        0     73,703    8.3

SYSAUX

346,094       7    5.6     3.9      112,744        2          0    0.0

SYSTEM

101,771       2    7.9     3.5       25,098        0        653    2.7
具体来说,寻找Rd(ms)。如果每次读超过20ms,你可能需要启动调查操作系统的瓶颈。

备注:你应该忽略相对空闲的表空间/文件,如果你有问题是1000万读太慢的问题不可能是由10次读的表空间/文件引起的问题。
要进一步调查,下面的文章可能会有帮助:

Document 223117.1 Troubleshooting I/O-related waits
虽然高的等待是’db file scattered read’ 和 ‘db file sequential read’ 与I/O相关,实际上正常是数据库要求执行SQL而出现的正常等待。实际上在调优数据库,前5等待事件你也会想看到这些等待事件,因为这将意味着不是有问题的等待事件。

关键是能够评估高等待是否表明一些SQL语句不使用最优路径(如前所述)或其他原因。如果有高等待事件’db file scattered read’,SQL可能没有使用最优访问路径,全表扫描而不是走索引(或者可能丢失索引或者不是最优索引)。此外,高等待事件’db file sequential read’ 可能表明SQL语句使用非选择性索引和读更多没用的索引块或者使用错的索引。因此这些等待可能指向不好的SQL执行计划。

不论什么情况,下一步要从AWR报告中检查消耗资源最高的SQL定位看起来过度的或可以进一步修改。

看SQL Statistics 部分。

上述提到,20%的时间用来等待CPU时间。这也是应该看看SQL统计信息。

记住下一步根据最高5个等待事件,在上面的例子,3个等待指向潜在最优的SQL,在下一个部分要调查。

如果你没有发现闩等待,闩没有造成重大的问题。因此你不需要对闩等待进一步调查。

通常,如果数据库比较慢,最高5个等待事件包含”CPU” 和”db file sequential read” 和”db file scattered read”在任何顺序,然后通常是直接跳转到Top SQL部分 (通过逻辑和物理读),调用Sql调优向导来确保他们有效的运行。

  • SQL Statistics

AWR报告显示一些不同的SQL统计信息:
不同的SQL统计信息子部分根据前5等待事件部分进行检查。

在我们的例子里,高等待事件是’db file scattered read’ , ‘db file sequential read’ 和CPU,因此,我们最关心基于CPU时间,get和reads排序的SQL。
经常查看’SQL ordered by gets’ 是一种方便的指向通常high buffer gets,适用于调优:

SQL ordered by Gets

-> Resources reported for PL/SQL code includes the resources used by all SQL

statements called by the code.

-> Total Buffer Gets:   4,745,943,815

-> Captured SQL account for     122.2% of Total

 

Gets              CPU     Elapsed

Buffer Gets   Executions    per Exec   %Total Time (s)  Time (s)    SQL Id

————– ———— ———— —— ——– ——— ————-

1,228,753,877          168  7,314,011.2   25.9  8022.46   8404.73 5t1y1nvmwp2

SELECT ADDRESSID”,CURRENT$.”ADDRESSTYPEID”,CURRENT$URRENT$.”ADDRESS3″,

CURRENT$.”CITY”,CURRENT$.”ZIP”,CURRENT$.”STATE”,CURRENT$.”PHONECOUNTRYCODE”,

CURRENT$.”PHONENUMBER”,CURRENT$.”PHONEEXTENSION”,CURRENT$.”FAXCOU

 

1,039,875,759   62,959,363         16.5   21.9  5320.27   5618.96 grr4mg7ms81

Module: DBMS_SCHEDULER

INSERT INTO “ADDRESS_RDONLY” (“ADDRESSID”,”ADDRESSTYPEID”,”CUSTOMERID”,”

ADDRESS1″,”ADDRESS2″,”ADDRESS3″,”CITY”,”ZIP”,”STATE”,”PHONECOUNTRYCODE”,”PHONENU

 

854,035,223          168  5,083,543.0   18.0  5713.50   7458.95 4at7cbx8hnz

SELECT “CUSTOMERID”,CURRENT$.”ISACTIVE”,CURRENT$.”FIRSTNAME”,CURRENT$.”LASTNAME”,CU<

RRENT$.”ORGANIZATION”,CURRENT$.”DATEREGISTERED”,CURRENT$.”CUSTOMERSTATUSID”,CURR

ENT$.”LASTMODIFIEDDATE”,CURRENT$.”SOURCE”,CURRENT$.”EMPLOYEEDEPT”,CURRENT$.

调优可以手动执行或调用SQL 调优向导:

Document 271196.1 Automatic SQL Tuning – SQL Profiles.

Document 262687.1 How to use the Sql Tuning Advisor.
Document 276103.1 PERFORMANCE TUNING USING ADVISORS AND MANAGEABILITY FEATURES: AWR, ASH, and ADDM and Sql Tuning Advisor.

Note: Use of the SQL Tuning Advisor requires the Oracle Tuning Pack License:
http://docs.oracle.com/database/121/DBLIC/options.htm#DBLIC139

 

Analysis:

    • -> Total Buffer Gets: 4,745,943

假设这是一个小时的报告,是一个大量的获取,因此这是一个值得研究Top SQL语句,以确保他们正在采取最优路径。

->Individual Buffer Gets
各个语句获取缓存区的值显示非常高,最低的值850百万。这三条语句实际指向2个不同的原因:

过多的Buffer Gets/Execution
SQL_IDs ‘5t1y1nvmwp2’ 和 ‘4at7cbx8hnz’只执行168次, 但是每次执行读超过5百万buffers。这个SQL语句调优的主要候选对象,由于缓冲区读入每个执行的数量是如此之高。

过多的执行
SQL_ID ‘grr4mg7ms81’ 每次执行只要16次buffer.调整这个语句无法明显降低。然而,这个语句的问题是执行的次数太多-6500万次。
改变在其中的调用方式可能在这里有最大的影响 – 这可能的语句被称一个循环调用,每记录一次,如果它可以被调用一次处理多个记录,则存在潜在规模重大的节约。

通过和基线进行比较,可以看到当数据库表现良好时执行这些SQL语句是否也读取这么多的数据。如果之前也是这样,他们这样做那么他们就不是问题的原因,并可以忽略不计(虽然有可能改善他们使广泛受益)。

 

Other SQL Statistic Sections

正如前面提到的,也有一些不同的报表部分,用来帮助明确原因。如果没有明确的原因,则有可能是只要少量好处。以下部分概述了一些潜在的原因和用途:

  • Load Profile

Dependent on the waits, the load profile section either provides useful general background information or specific details related to potential issues. 依赖于等待,Load Profile部分提供有用的一般后台信息或与之相关的潜在问题的具体细节。

Load Profile

~~~~~~~~~~~~                            Per Second       Per Transaction

—————       —————

Redo size:          4,585,414.80          3,165,883.14

Logical reads:             94,185.63             65,028.07

Block changes:             40,028.57             27,636.71

Physical reads:              2,206.12              1,523.16

Physical writes:              3,939.97              2,720.25

User calls:                 50.08                 34.58

Parses:                 26.96                 18.61

Hard parses:                  1.49                  1.03

Sorts:                 18.36                 12.68

Logons:                  0.13                  0.09

Executes:              4,925.89              3,400.96

Transactions:                  1.45

 

% Blocks changed per Read:   42.50    Recursive Call %:    99.19

Rollback per transaction %:   59.69       Rows per Sort:  1922.64

在该示例中,等待部分显示问题与SQL的执行有关,因此负载资料可在这方面进行细节检查,尽管它不是信息的要来源。

如果您正在看AWR报告进行一般的调优,您会看到负载资料部分显示具有很高的重做活动和搞得物理写。高物理写入比较高重做的活动。在这个负载里写比读多,有42%的块发生变化。

此外,存在比软解析少的硬解析。
如果有一个互斥等待为前五等待事件,如’library cache: mutex X’,那么统计如整体解析比例会更有相关性。

再次,和基线进行对比将提供最佳的信息,例如,检查以查看redo size, users calls, 和parsing的负载是否改变。

  • Instance Efficiency

再次,实例的效率状态用来进行一般的优化,而不是解决具体问题(除非等待指向这些)

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Buffer Nowait %:   99.91       Redo NoWait %:  100.00

Buffer  Hit   %:   98.14    In-memory Sort %:   99.98

Library Hit   %:   99.91        Soft Parse %:   94.48

Execute to Parse %:   99.45         Latch Hit %:   99.97

Parse CPU to Parse Elapsd %:   71.23     % Non-Parse CPU:   99.00

但从我们的例子中,这里有一个重要的统计信息是’% Non-Parse CPU’,因为这表明,在几乎所有的CPU事件在前五等待事件用于执行而不是解析,这意味着调整SQL可能有助于改善这一点。

如果我们调整,那么94.48%软解析率显示硬解析是一小部分。高执行解析%表示游标的使用情况良好。一般情况下,我们希望在这里统计接近100%,但请记住,百分之几的可能会依赖于不一样应用程序。例如,在数据仓库环境中,硬解析可能更高由于物化视图和或直方图的使用。因此在此与数据库表现良好时的基线进行对比是很重要的。

Latch Activity
在这个例子中,我们没有看到对闩有显著的等待,因此这部分可以被忽略。
但是,如果闩等待是显著的,那么我们将looking for high latch sleeps under Latch Sleep Breakdown for latch free waits:

Latch Sleep Breakdown

 

* ordered by misses desc

 

Latch Name

—————————————-

Get Requests      Misses      Sleeps  Spin Gets   Sleep1   Sleep2   Sleep3

————– ———– ———– ———- ——– ——– ——–

cache buffers chains

2,881,936,948       3,070,271      41,336  3,031,456        0        0        0

row cache objects

941,375,571   1,215,395         852  1,214,606        0        0        0

object queue header operation

763,607,977     949,376      30,484    919,782        0        0        0

cache buffers lru chain

376,874,990     705,162       3,192    702,090        0        0        0

在这里,最高的闩是高速缓存缓冲区链。高速缓存缓冲区链闩锁保护缓冲区高速缓存的认为我们已经从磁盘检索数据的缓冲区。这是一个完全正常的闩锁以便查看正在读取数据时。
在我们的例子中,虽然得到高28亿缓冲区获取,睡眠41336是较低的。每睡眠丢失比率低(Avg Slps/Miss)。这样是因为该服务器能够处理这种数据量,因此对高速缓存缓冲区链闩无显著争用。
对于其他的的空闲等待,请查看下面文章调查确定是什么类型的闩锁:

Document 413942.1 How to Identify Which Latch is Associated with a “latch free” wait

Notable timed and wait events:

  • CPU time events

CPU时间事件在AWR报告的前五等待事件里不能表明问题。然而,如果性能慢的高CPU使用率,开始调查这个事件。首先在AWR里先查看根据CPU时间排序的SQL:

SQL ordered by CPU Time

-> Resources reported for PL/SQL code includes the resources used by all SQL

statements called by the code.

-> % Total is the CPU Time divided into the Total CPU Time times 100

-> Total CPU Time (s):          56,207

-> Captured SQL account for      114.6% of Total

 

CPU      Elapsed                  CPU per          % Total

Time (s)   Time (s)  Executions     Exec (s) % Total DB Time SQL Id

———- ———- ———— ———– ——- ——- ————-

20,349     24,884          168      121.12    36.2     9.1 7bbhgqykv3cm9

Module: DBMS_SCHEDULER

DECLARE job BINARY_INTEGER := :job; next_date TIMESTAMP WITH TIME ZONE := :myda

te; broken BOOLEAN := FALSE; job_name VARCHAR2(30) := :job_name; job_subname

VARCHAR2(30) := :job_subname; job_owner VARCHAR2(30) := :job_owner; job_start

TIMESTAMP WITH TIME ZONE := :job_start; job_scheduled_start TIMESTAMP WITH TIME

 

 

Analysis:

    • -> Total CPU Time (s): 56,207

这是否显著取决于报告的持续时间。

    • 最高CPU使用的SQL用了20,349 秒
    • Total DB of time 显示是 9.1%.
    • 执行次数 168

Actions:

一旦你已经确定了所使用的CPU最高的SQL语句,探讨原因用这种方法。

    • 看看执行的次数,看是否适合于本语句。过多的执行可能表明该语句被调用过于频繁,有可能执行它为a group of rows rather than row by row(即在一个批处理执行它)。
    • 是否每次执行过多的CPU – 这可能表明该语句本身是低效率的。
    • 另外,看在AWR报告中的其他SQL统计信息,看相应SQL ID是否在其他部分显示过高的值的问题,然后适当的处理语句。

Other Potential CPU related Issues:

    • Check to see if other waits follow the high CPU timed event.

例如, cursor: pin S waits可能引起高CPY,参见下面文章:

Document 6904068.8 Bug 6904068 – High CPU usage when there are “cursor: pin S” waits

    • High External CPU usage

如果数据库外部进程使用高CPU,那么这可能是防止数据库进程得到他们需要的CPU和影响数据库性能。在这种情况下,运行oswatcher或其他操作系统诊断工具找到哪个进程正在使用高CPU。

Document 433472.1 OS Watcher For Windows (OSWFW) User Guide

    • Troubleshooting CPU usage

下面的文章显示如何进一步诊断高CPU使用:

Document 164768.1 Troubleshooting: High CPU Utilization

  • ‘Log file sync’ waits

当一个用户会话提交或回滚,刷写重做日志缓冲区的重做日志到重做日志里。AWR报告是非常有用的,定位这个问题是I / O或是其他方面。下面的文章专门处理这种症状

Document 1376916.1 Troubleshooting: “Log File Sync” Waits
Document 34592.1WAITEVENT: “log file sync”

  • Buffer busy waits

这是当一个会话试图从缓冲区获得一个缓冲区但缓冲区很忙,要么被另一个会话读或另一个会话以不兼容的模式占用。为了找到那个快在忙和为什么,使用下面的文章:

Document 155971.1 Resolving Intense and “Random” Buffer Busy Wait Performance Problems
Document 34405.1 WAITEVENT: “buffer busy waits”

  • Waits for ‘Cursor: mutex/pin’

如果有互斥等待如’Cursor: pin S wait on X’或’Cursor: mutex X’等,那么这些表明解析问题。在此基础上在’SQL ordered by Parse Calls’和’SQL ordered by Version Count’下寻找高解析语句或高版本计数语句,这是最有可能的原因的问题。以下可以帮助进一步分析:

Document 1356828.1 FAQ: ‘cursor: mutex ..’ / ‘cursor: pin ..’ / ‘library cache: mutex ..’ Type Wait Events
Document 1349387.1 Troubleshooting ‘cursor: pin S wait on X’ waits.

 

Troubleshooting Other Issues

指导其他性能问题的诊断,参照:

Document 1377446.1 Troubleshooting Performance Issues

 

Use of ADDM Reports alongside AWR

ADDM报告可以和AWR报告一起使用;协助诊断,因为它们提供了具体建议可以帮助指向潜在的问题。下面是一个ADDM报告示例:

Document 250655.1How to use the Automatic Database Diagnostic Monitor:
输出样例:

DETAILED ADDM REPORT FOR TASK ‘SCOTT_ADDM’ WITH ID 5
—————————————————-

Analysis Period: 17-NOV-2003 from 09:50:21 to 10:35:47
Database ID/Instance: 494687018/1
Snapshot Range: from 1 to 3
Database Time: 4215 seconds
Average Database Load: 1.5 active sessions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FINDING 1: 65% impact (2734 seconds)
————————————
PL/SQL execution consumed significant database time.

RECOMMENDATION 1: SQL Tuning, 65% benefit (2734 seconds)
ACTION: Tune the PL/SQL block with SQL_ID fjxa1vp3yhtmr. Refer to
the “Tuning PL/SQL Applications” chapter of Oracle’s “PL/SQL
User’s Guide and Reference”
RELEVANT OBJECT: SQL statement with SQL_ID fjxa1vp3yhtmr
BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;

FINDING 2: 35% impact (1456 seconds)
————————————
SQL statements consuming significant database time were found.

RECOMMENDATION 1: SQL Tuning, 35% benefit (1456 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
gt9ahqgd5fmm2.
RELEVANT OBJECT: SQL statement with SQL_ID gt9ahqgd5fmm2 and
PLAN_HASH 547793521
UPDATE bigemp SET empno = ROWNUM

FINDING 3: 20% impact (836 seconds)
———————————–
The throughput of the I/O subsystem was significantly lower than expected.

RECOMMENDATION 1: Host Configuration, 20% benefit (836 seconds)
ACTION: Consider increasing the throughput of the I/O subsystem.
Oracle’s recommended solution is to stripe all data file using
the SAME methodology. You might also need to increase the
number of disks for better performance.

RECOMMENDATION 2: Host Configuration, 14% benefit (584 seconds)
ACTION: The performance of file
D:\ORACLE\ORADATA\V1010\UNDOTBS01.DBF was significantly worse
than other files. If striping all files using the SAME
methodology is not possible, consider striping this file over
multiple disks.
RELEVANT OBJECT: database file
“D:\ORACLE\ORADATA\V1010\UNDOTBS01.DBF”

SYMPTOMS THAT LED TO THE FINDING:
Wait class “User I/O” was consuming significant database time.
(34% impact [1450 seconds])

FINDING 4: 11% impact (447 seconds)
———————————–
Undo I/O was a significant portion (33%) of the total database I/O.

NO RECOMMENDATIONS AVAILABLE

SYMPTOMS THAT LED TO THE FINDING:
The throughput of the I/O subsystem was significantly lower than
expected. (20% impact [836 seconds])
Wait class “User I/O” was consuming significant database time.
(34% impact [1450 seconds])

FINDING 5: 9.9% impact (416 seconds)
————————————
Buffer cache writes due to small log files were consuming significant
database time.

RECOMMENDATION 1: DB Configuration, 9.9% benefit (416 seconds)
ACTION: Increase the size of the log files to 796 M to hold at
least 20 minutes of redo information.
ADDM报告比AWR报告提供高可读性格式的可行建议。然而,ADDM应该和AWR统计信息一起使用进行准确的诊断。

Other AWR reference Articles

读取AWR报告的其他部分时下面这些文章可以提供帮助:

Document 786554.1 How to Read PGA Memory Advisory Section in AWR and Statspack Reports
Document 754639.1 How to Read Buffer Cache Advisory Section in AWR and Statspack Reports

Document 1301503.1 Troubleshooting: AWR Snapshot Collection issues
Document 1363422.1 Automatic Workload Repository (AWR) Reports – Start Point

Statspack

AWR报告取代传统报告如statspack和bstat / estat。下面是一个链接,文章概述了如何阅读statspack报告:

http://www.oracle.com/technetwork/database/focus-areas/performance/statspack-opm4-134117.pdf

额外的信息可以在下面这些文章中获取:

Document 94224.1 FAQ- Statspack Complete Reference
Document  394937.1 Statistics Package (STATSPACK) Guide

Document 149113.1  Installing and Configuring StatsPack Package
Document 149121.1 Gathering a StatsPack snapshot
Document 228913.1  Systemwide Tuning using STATSPACK Reports


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *