如何使用AWR报告来诊断数据库性能问题

对于数据库整体的性能问题，AWR的报告是一个非常有用的诊断工具。

一般来说，当检测到性能问题时，我们会收集覆盖了发生问题的时间段的AWR报告-但是最好只收集覆盖1个小时时间段的AWR报告-如果时间过长，那么AWR报告就不能很好的反映出问题所在。还应该收集一份没有性能问题的时间段的AWR报告，作为一个参照物来对比有问题的时间段的AWR报告。这两个AWR报告的时间段应该是一致的，比如都是半个小时的，或者都是一个小时的。

Interpretation

在处理性能问题时，我们最关注的是数据库正在等待什么。

当进程因为某些原因不能进行 *** 作时，它需要等待。花费时间最多的等待事件是我们最需要关注的，因为降低它，我们能够获得最大的好处。

AWR报告中的"Top 5 Timed Events"部分就提供了这样的信息，可以让我们只关注主要的问题。

Top 5 Timed Events

正如前面提到的，"Top 5 Timed Events"是AWR报告中最重要的部分。它指出了数据库的sessions花费时间最多的等待事件，如下：

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 296 User I/O

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

CPU time 56,207 205

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

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

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

Top 5 Events部分包含了一些跟Events（事件）相关的信息。它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间；这一部分是按照每个Event占总体call time的百分比来进行排序的。

根 据Top 5 Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据 库中的并发用户数进行评估。如：10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题；10个用户引起的1000万次的等待事件比 10,000个用户引起的相同的等待要更有问题。

就像上面的例子，将近60%的时间是在等待IO相关的事件。

其他20%的时间是花在使用或等待CPU time上。过高的CPU使用经常是性能不佳的SQL引起的（或者这些SQL有可能用更少的资源完成同样的 *** 作）；对于这样的SQL，过多的IO *** 作也是一个症状。关于CPU使用方面，我们会在之后讨论。

在以上基础上，我们将调查是否这个等待事件是有问题的。若有问题，解决它；若是正常的，检查下个等待事件。

过多的IO相关的等待一般会有两个主要的原因：

Top 5 Events部分的显示的信息会帮助我们检查：

需要注意，接下来的分析步骤取决于我们在TOP 5部分的发现。在上面的例子里，3个top wait event表明问题可能与SQL语句执行计划不好有关，所以接下来我们要去分析"SQL Statistics"部分。

同样的，因为我们并没有看到latch相关的等待，latch在我们这个例子里并没有引发严重的性能问题；那么我们接下来就完全不需要分析latch相关的信息。

一 般来讲，如果数据库性能很慢，TOP 5等待事件里"CPU"， "db file sequential read" 和"db file scattered read" 比较明显（不管它们之间的顺序如何），我们总是需要检查Top SQL (by logical and physical reads)部分；调用SQL Tuning Advisor或者手工调优这些SQL来确保它们是有效率的运行。

是否数据库做了大量的读 *** 作：

上面的图显示了在这段时间里两类读 *** 作都分别大于1000万，这些 *** 作是否过多取决于报告的时间是1小时或1分钟。我们可以检查AWR报告的elapsed time如果这些读 *** 作确实是太多了，接下来我们需要检查AWR报告中 SQL Statistics 部分的信息，因为读 *** 作都是由SQL语句发起的。

是否是每次的IO读 *** 作都很慢：

上面的图显示了在这段时间里两类读 *** 作平均的等待时间是小于8ms的

至于8ms是快还是慢取决于底层的硬件设备；一般来讲小于20ms的都可以认为是可以接受的。

我们还可以在AWR报告"Tablespace IO Stats"部分得到更详细的信息

Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15

-> ordered by IOs (Reads + Writes) desc

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 76 46 145,263,880 2,883 3,844,161 83

USER

204,834 4 107 10 17,849,021 354 15,249 98

UNDOTS1

19,725 0 30 10 10,064,086 200 1,964 49

AE_TS

4,287,567 85 54 67 932 0 465,793 37

TEMP

2,022,883 40 00 58 878,049 17 0 00

UNDOTS3

1,310,493 26 46 10 941,675 19 43 00

TS_TX_IDX

1,884,478 37 73 10 23,695 0 73,703 83

>SYSAUX

346,094 7 56 39 112,744 2 0 00

SYSTEM

101,771 2 79 35 25,098 0 653 27

如上图，我们关心Av Rd(ms)的指标。如果它高于20ms并且同时有很多读 *** 作的，我们可能要开始从OS的角度调查是否有潜在的IO问题。

注：对于一些比较空闲的tablespace/files,我们可能会得到一个比较大的Av Rd(ms)值；对于这样的情况，我们应该忽略这样的tablespace/files;因为这个很大的值可能是由于硬盘自旋(spin)引起的，没有太大的参考意义。比如对

于一个有1000万次读 *** 作而且很慢的系统，引起问题的基本不可能是一个只有10次read的tablespace/file

虽 然高"db file scattered read"和"db file sequential read"等待可以是I / O相关的问题，但是很多时候这些等待也可能是正常的；实际上，对一个已经性能很好的数据库系统，这些等待事件往往在top 5等待事件里，因为这意味着您的数据库没有那些真正的“问题”。

诀窍是能够评估引起这些等待的语句是否使用了最优的访问路径。如果"db file scattered read"比较高，那么相关的SQL语句可能使用了全表扫描而没有使用索引（也许是没有创建索引，也许是没有合适的索引）；相应的，如果"db file sequential read"过多，则表明也许是这些SQL语句使用了selectivity不高的索引从而导致访问了过多不必要的索引块或者使用了错误的索引。这些等待可 能说明SQL语句的执行计划不是最优的。

接下来就需要通过AWR来检查这些top SQL是否可以进一步的调优，我们可以查看AWR报告中 SQL Statistics 的部分

上面的例子显示了20%的时间花在了等待或者使用CPU上，我们也需要检查 SQL statistics 部分来进一步的分析。

数据库做了太多的读 *** 作

每次的IO读 *** 作都很慢

事件"db file scattered read"一般表明正在做由全表扫描或者index fast full scan引起的多块读。

事件"db file sequential read"一般是由不能做多块读的 *** 作引起的单块读（如读索引）

SQL Statistics

AWR包含了一些不同的SQL统计值：

根据Top 5 部分的Top Wait Event不同，我们需要检查不同的SQL statistic。

在我们这个例子里，Top Wait Event是"db file scattered read"，"db file sequential read"和CPU；我们最需要关心的是SQL ordered by CPU Time, Gets and Reads。

我们会从"SQL ordered by gets"入手，因为引起高buffer gets的SQL语句一般是需要调优的对象。

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 1222% of Total

Gets CPU Elapsed

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

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

1,228,753,877 168 7,314,0112 259 802246 840473 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 165 219 532027 561896 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,5430 180 571350 745895 4at7cbx8hnz

SELECT "CUSTOMERID",CURRENT$"ISACTIVE",CURRENT$"FIRSTNAME",CURRENT$"LASTNAME",CU<

RRENT$"ORGANIZATION",CURRENT$"DATEREGISTERED",CURRENT$"CUSTOMERSTATUSID",CURR

ENT$"LASTMODIFIEDDATE",CURRENT$"SOURCE",CURRENT$"EMPLOYEEDEPT",CURRENT$

对这些Top SQL,可以手工调优，也可以调用SQL Tuning Advisor。

分析：

Other SQL Statistic Sections

就像之前提到的那样，AWR报告中有很多不同的部分用来分析各种不同的问题。如果特定的问题并没有出现，那么分析AWR报告的这些部分并不能有很大的帮助。

下面提到了一些可能的问题：

Waits for 'Cursor: mutex/pin' 如 果发现了一些像"Cursor: pin S wait on X" 或"Cursor: mutex X" 类的mutex等待，那么可能是由于parsing引起的问题。检查"SQL ordered by Parse Calls" 和"SQL ordered by Version Count"部分的Top SQL，这些SQL可能引起这类的问题。

单次执行buffer gets过多

SQL_ID为'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL语句总共被执行了168次，但是每次执行引起的buffer gets超过500万。这两个SQL应该是主要的需要调优的候选者。

执行次数过多

SQL_ID 'grr4mg7ms81' 每次执行只是引起16次buffer gets,减少这条SQL每次执行的buffer get可能并不能显著减少总共的buffer gets。这条语句的问题是它执行的太频繁了，6500万次。

改变这条SQL的执行次数可能会更有意义。这个SQL看起来是在一个循环里面被调用，如果可以让它一次处理的数据更多也许可以减少它执行的次数。

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

假设这是一个一个小时的AWR报告，4,745,943,815是一个很大的值；所以需要进一步分析这个SQL是否使用了最优的执行计划

Individual Buffer Gets

上面的例子里单个的SQL的buffer get非常多，最少的那个都是8亿5千万。这三个SQL指向了两个不同的引起过多buffers的原因：

注意：对于某些非常繁忙的系统来讲，以上的数字可能都是正常的。这时候我们需要把这些数字跟正常时段的数字作对比，如果没有什么太大差别，那么这些SQL并不是引起问题的元凶（虽然通过调优这些SQL我们仍然可以受益）

Load Profile

根据Top 5等待事件的不同，"Load Profile"可以提供一些有用的背景资料或潜在问题的细节信息。

Load Profile

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

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

Redo size: 4,585,41480 3,165,88314

Logical reads: 94,18563 65,02807

Block changes: 40,02857 27,63671

Physical reads: 2,20612 1,52316

Physical writes: 3,93997 2,72025

User calls: 5008 3458

Parses: 2696 1861

Hard parses: 149 103

Sorts: 1836 1268

Logons: 013 009

Executes: 4,92589 3,40096

Transactions: 145

% Blocks changed per Read: 4250 Recursive Call %: 9919

Rollback per transaction %: 5969 Rows per Sort: 192264

在这个例子里，Top 5 Events部分显示问题可能跟SQL的执行有关，那么我们接下来检查load profile部分。

如果您检查AWR report是为了一般性的性能调优，那么可以看到有比较多的redo activity和比较高的physical writes Physical writes比physical read要高，并且有42%的块被更改了

此外，hard parse的次数要少于soft parse

如果mutex等待事件比较严重，如"library cache: mutex X"，那么查看所有parse的比率会更有用。

当然，如果把Load Profile部分跟正常时候的AWR报告做比较会更有用，比如，比较redo size, users calls, 和 parsing这些性能指标。

Instance Efficiency

Instance Efficiency部分更适用于一般性的调优，而不是解决某个具体问题（除非等待事件直接指向这些指标）。

Instance Efficiency Percentages (Target 100%)

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

Buffer Nowait %: 9991 Redo NoWait %: 10000

Buffer Hit %: 9814 In-memory Sort %: 9998

Library Hit %: 9991 Soft Parse %: 9448

Execute to Parse %: 9945 Latch Hit %: 9997

Parse CPU to Parse Elapsd %: 7123 % Non-Parse CPU: 9900

从我们的这个例子来看，最有用的信息是%Non-Parse CPU，它表明几乎所有的CPU都消耗在了Execution而不是Parse上，所以调优SQL会对性能有改善。

9448％ 的soft parse比率显示hard parse的比例很小，这是可取的。Execute to Parse %很高，说明cursor被很好的重用了。我们总是期望这里的值都是接近100%,但是因为应用的不同，如果这个部分的参数的某些值很小，也是可以认为没 有问题的；如在数据仓库环境，hard parse因为使用了物化视图或histogram而变得很高。所以，重要的是，我们需要把这部分信息和正常时候的AWR报告做比较来判断是否有问题。

方法如下：

1、首先在浏览器地址栏输入知网的网站，或直接百度搜索找到知网。进入中国知网页面后，再单击高级检索。

2、在高级检索页面的作者和作者单位栏目处输入作者的姓名、单位全称或学校全称，输入完成之后单击检索，在排序选项里单击发表时间将搜索结果按年限排序。

3、选中需要检索的论文，再单击导出／参考文献。

4、接着会跳转到文献管理中心导出的页面，该页面中再次选中需要检索的论文，单击导出／参考文献。

5、最后会跳转到文献输出页面。单击打印即可。

报告说明

在学术论文、期刊发表中，只有稿件被收录了，才是论文成功发表的最终标志。但如何证明稿件被收录了呢？那就需要检索报告。检索报告是证明稿件是否被收录最直接的证据。

不是所有的期刊都需要开具检索报告，目前需要开具检索报告的数据库主要有以下几个：SCIE、SSCI、EI 、CSSCI和CSCD，只有被这些数据库收录的稿件才需要打印检索报告，其他数据库则无需打印。

>

以连接ORACLE数据库为例：

var conn = new ActiveXObject("ADODBConnection");

//创建数据集对象

var rs = new ActiveXObject("ADODBRecordset");

try{ 

//如果不知道如何配置连接串，可以通过配置UDL文件后用文本编辑器打开获得 

var connectionstring = "Provider=OraOLEDBOracle1;Password=pwd;Persist Security Info=True;User ID=username;Data Source=ORA";  

//打开连接 

connopen(connectionstring);

//查询语句 

var sql = " select  from tb_col ";  

//打开数据集（即执行查询语句） 

rsopen(sql,conn);  

//遍历所有记录 

while(!rseof){

  //WScript是Windows 的脚本宿主对象，详细情况请在windows帮助里查找。  

  //WScriptEcho输出记录的内容  

  WScriptEcho(rsFields("id") + "\t" + rsFields("name") + "\n");  

  //下一条记录  

  rsmoveNext(); } 

  //关闭记录集 

  rsclose(); 

  //关闭数据库连接 

  connclose();} catch(e){ 

  //异常报告 

  WScriptEcho(emessage);} finally{ 

  }

数据库连接串，具体配置请参考：>

定义：awr报告是oracle 10g下提供的一种性能收集和分析工具，它能提供一个时间段内整个系统资源使用情况的报告，通过这个报告，我们就可以了解一个系统的整个运行情况，这就像一个人全面的体检报告。

如何分析：

在看awr报告的时候，我们并不需要知道所有性能指标的含义，就可以判断出问题的所在，这些性能指标其实代表了oracle内部实现，对oracle理解的越深，在看awr报告的时候，对数据库性能的判断也会越准确

在看性能指标的时候，心里先要明白，数据库出现性能问题，一般都在三个地方，io，内存，cpu，这三个又是息息相关的（ps：我们先假设这个三个地方都没有物理上的故障），当io负载增大时，肯定需要更多的内存来存放，同时也需要cpu花费更多的时间来过滤这些数据，相反，cpu时间花费多的话，有可能是解析sql语句，也可能是过滤太多的数据，到不一定是和io或内存有关系了

当我们把一条sql送到数据库去执行的时候，我们要知道，什么时候用到cpu，什么时候用到内存，什么时候用到io

1 cpu：解析sql语句，尝试多个执行计划，最后生成一个数据库认为是比较好的执行计划，不一定是最优的，因为关联表太多的时候，数据库并不会穷举所有的执行计划，这会消耗太多的时间，oracle怎么就知道这条数据时你要，另一个就不是你要的呢，这是需要cpu来过滤的

2 内存：sql语句和执行计划都需要在内存保留一段时间，还有取到的数据，根据lru算法也会尽量在内存中保留，在执行sql语句过程中，各种表之间的连接，排序等 *** 作也要占用内存

3 io：如果需要的数据在内存中没有，则需要到磁盘中去取，就会用到物理io了，还有表之间的连接数据太多，以及排序等 *** 作内存放不下的时候，也需要用到临时表空间，也就用到物理io了

这里有一点说明的是，虽然oracle占用了8G的内存，但pga一般只占8G的20%，对于专用服务器模式，每次执行sql语句，表数据的运算等 *** 作，都在pga中进行的，也就是说只能用16G左右的内存，如果多个用户都执行

多表关联，而且表数据又多，再加上关联不当的话，内存就成为瓶颈了，所有优化sql很重要的一点就是，减少逻辑读和物理读

如何生成awr报告：

1：登陆对应的数据库服务器

2：找到oracle磁盘空间（d:oracle\product\1020\db_1\RDBMS\Admin)

3：执行cmd-cd d:回车

4: cd d:oracle\product\1020\db_1\RDBMS\Admin 回车

5：sqlplus 用户名/密码@服务连接名(例：sqlplus carmot_esz_1/carmot@igrp)

6：执行@awrrptsql 回车

第一步输入类型： html

第二步输入天数： 天数自定义（如1，代表当天，如果2，代表今天和昨天。。。）

第三步输入开始值与结束值：（你可以看到上面列出的数据，snap值）

这个值输入开始，与结束

第四步输入导出表的名称：名称自定义 回车

第五步，由程序自动导完。

第六：到d:oracle\product\1020\db_1\RDBMS\Admin 目录下。找到刚才生成的文件。 XXXXLST文件

具体分析过程：

在分析awr报告之前，首先要确定我们的系统是属于oltp，还是olap（数据库在安装的时候，选择的时候，会有一个选项，是选择oltp，还是olap）

对于不同的系统，性能指标的侧重点是不一样的，比如，library hit和buffer hit，在olap系统中几乎可以忽略这俩个性能指标，而在oltp系统中，这俩个指标就非常关键了

首先要看俩个时间

Elapsed: 24000 (mins) 表明采样时间是240分钟，任何数据都要通过这个时间来衡量，离开了这个采样时间，任何数据都毫无疑义

DB Time: 92,53795 (mins) 表明用户 *** 作花费的时候，包括cpu时间喝等待时间，也许有人会觉得奇怪，为什么在采样的240分钟过程中，用户 *** 作时间竟然有92537分钟呢，远远超过了

采样时间，原因是awr报告是一个数据的集合，比如在一分钟之内，一个用户等待了30秒，那么10个用户就等待了300秒，对于cpu的话，一个cpu处理了30秒，16个cpu就是4800秒，这些时间都是以累积的方式记录在awr报告中的。

再看sessions，可以看出连接数非常多

为了对数据库有个整体的认识，先看下面的性能指标

1 Buffer Nowait 说明在从内存取数据的时候，没有经历等待的比例，期望值是100%

2 Buffer Hit 说明从内存取数据的时候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因为这只是一个比例而已，举个例子，执行一条 sql语句，# 执行计划是需要取10000个数据块，结果内存中还真有这10000个数据块，那么比例是100%，表面上看是性能最高的，还有一个执行计划是需要500 个数据块，内存中有250个，另外250个需要在物理磁盘中取，

这种情况下，buffer hit是50%，结果呢，第二个执行计划性能才是最高的，所以说100%并不代表性能最好

3 Library Hit 说明sql在Shared Pool的命中率，期望值是100%

4 Execute to Parse 说明解析sql和执行sql之间的比例，越高越好，说明一次解析，到处执行，如果parse多，execute少的话，还会出现负数，因为计算公式是100（1-parse/execute）

5 Parse CPU to Parse Elapsd 说明在解析sql语句过程中，cpu占整个的解析时间比例，，期望值是100%，说明没有产生等待，需要说明的是，即使有硬解析，只要cpu没有出现性能问题，也是可以容忍的，比较硬解析也有它的好处的

6 Redo NoWait 说明在产生日志的时候，没有产生等待，期望值是100%

7 Soft Parse 说明软解析的比例，期望值是100%，有一点要说明的是，不要单方面的追求软解析的高比例，而去绑定变量，要看性能的瓶颈在哪里

8 Latch Hit 说明latch的命中率，期望值是100%，latch类似锁，是一种内存锁，但只会产生等待，不会产生阻塞，和lock还是有区别的，latch是在并发的情况下产生的

9 Non-Parse CPU 说明非解析cpu的比例，越高越好，用100减去这个比例，可以看出解析sql所花费的cpu，100-9930=07，说明花费在解析sql上的cpu很少

结合Time Model Statistics

可以看出，在整个sql执行时间（sql execute elapsed time）时间为5552019秒中，解析时间（parse time elapsed）用了36秒，硬解析时间（hard parse elapsed time）用了34秒虽然硬解析时间占了整个解析时间的绝大部分，但解析时间是花的很少的，所以可以判断出，sql的解析没有成为性能的瓶颈，进一步推测，sql在获取数据的过程中遇到了瓶 颈

继续看Top 5 Timed Events，从这里可以看出等待时间在前五位的是什么事件，基本上就可以判断出性能瓶颈在什么地方

1 buffer busy waits 说明在获取数据的过程中，频繁的产生等待事件，很有可能产生了热点块，也就是说，很多会话都去读取同样的数据块，这一事件等待了5627394次，总共等待了5322924秒，平均等待时间为946毫秒，而且频率也是最高的，有959%，等待类别是并发

这里有一个概念：oracle *** 作的最小单位是块，当一个会话要修改这个块中的一条记录，会读取整个块，如果另一个会话要修改的数据也正好在这个块中，虽然这俩个

2 会话修改的记录不一样，也会产生等待direct path write temp和direct path read temp 说明用到了临时表空间，那我们再看一下Tablespace IO Stats

各项指标都是非常高的，再根据上面的In-memory Sort是100%，没有产生磁盘排序，也就在排序的时候没有用到临时表空间，进一步推测，多个session，每个session执行的sql语句中多表关联，产生了很多中间数据，pga内存中放不下，

用到了临时表空间，也有可能是用到了lob字段，在用lob字段的时候，也会用到临时表

继续看SQL Statistics

根据buffer busy waits等待次数，时间，频率都是最高的，我们重点看逻辑读，物理读，和执行时间最长的sql，把排在前几位的拿出来优化

优化的原则为降低物理读，逻辑读，sql语句中的子 *** 作执行次数尽量少，在看oracle估计出来的执行计划是看不出子 *** 作的执行次数的，要看运行时的执行计划

有兴趣的话还可以看一下Segment Statistics

列出了用到的索引和表的使用情况，从这里也能看出索引和表的使用频率

也可以看一下Load Profile

里面列出了每秒，每个事务所产生的日志，逻辑读和物理读等指标

以上就是关于如何使用AWR报告来诊断数据库性能问题全部的内容，包括:如何使用AWR报告来诊断数据库性能问题、论文检索报告怎么弄、SGS报告在线数据库网址是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！