如何使用AWR报告来诊断数据库性能问题Word文档格式.docx
《如何使用AWR报告来诊断数据库性能问题Word文档格式.docx》由会员分享，可在线阅读，更多相关《如何使用AWR报告来诊断数据库性能问题Word文档格式.docx（50页珍藏版）》请在冰豆网上搜索。
Logfilesync'
waits
Bufferbusywaits
诊断其他问题
使用ADDM的报告
其他的AWR参考文章
Statspack
References
Appliesto:
OracleDatabase-EnterpriseEdition-Version10.2.0.1andlater
Informationinthisdocumentappliestoanyplatform.
适用于Oracle数据库企业版10.2.0.1及其之后的版本，适用于任何平台。
本文旨在提供如何解释跟数据库性能问题息息相关的AWR信息。
有些问题是无法预见的，但大部分其它的问题如果及早发现一些征兆其实是可以避免的。
同时，如果问题确实发生了，那么收集问题发生时的信息就非常重要。
有关于如何主动避免问题及诊断信息的收集，请参见：
Document1482811.1BestPractices:
ProactivelyAvoidingDatabaseandQueryPerformanceIssues
Document1477599.1BestPracticesAroundDataCollectionForPerformanceIssues
对于数据库整体的性能问题，AWR的报告是一个非常有用的诊断工具。
一般来说，当检测到性能问题时，我们会收集覆盖了发生问题的时间段的AWR报告-但是最好只收集覆盖1个小时时间段的AWR报告-如果时间过长，那么AWR报告就不能很好的反映出问题所在。
还应该收集一份没有性能问题的时间段的AWR报告，作为一个参照物来对比有问题的时间段的AWR报告。
这两个AWR报告的时间段应该是一致的，比如都是半个小时的，或者都是一个小时的。
关于如何收集AWR报告，请参照如下文档：
Document1363422.1AutomaticWorkloadRepository（AWR）Reports-StartPoint
注：
最好一开始我们从ADDM报告入手，因为对应时间段的ADDM报告往往已经指出了问题所在。
参见:
UseofADDMReportsalongsideAWR
在处理性能问题时，我们最关注的是数据库正在等待什么。
当进程因为某些原因不能进行操作时，它需要等待。
花费时间最多的等待事件是我们最需要关注的，因为降低它，我们能够获得最大的好处。
AWR报告中的"
Top5TimedEvents"
部分就提供了这样的信息，可以让我们只关注主要的问题。
∙Top5TimedEvents
正如前面提到的，"
是AWR报告中最重要的部分。
它指出了数据库的sessions花费时间最多的等待事件，如下：
Top5TimedEventsAvg%Total
~~~~~~~~~~~~~~~~~~waitCall
EventWaitsTime（s）（ms）TimeWaitClass
---------------------------------------------------------------------------
dbfilescatteredread10,152,56481,327829.6UserI/O
dbfilesequentialread10,327,23175,878727.6UserI/O
CPUtime56,20720.5
readbyothersession4,397,33033,455812.2UserI/O
PXDeqCredit:
sendblkd31,39826,5768469.7Other
-------------------------------------------------------------
Top5Events部分包含了一些跟Events（事件）相关的信息。
它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间；
这一部分是按照每个Event占总体calltime的百分比来进行排序的。
根据Top5Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。
等待事件需要根据报告期的持续时间和当时数据库中的并发用户数进行评估。
如：
10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题；
10个用户引起的1000万次的等待事件比10,000个用户引起的相同的等待要更有问题。
就像上面的例子，将近60%的时间是在等待IO相关的事件。
o事件"
dbfilescatteredread"
一般表明正在做由全表扫描或者indexfastfullscan引起的多块读。
dbfilesequentialread"
一般是由不能做多块读的操作引起的单块读（如读索引）
其他20%的时间是花在使用或等待CPUtime上。
过高的CPU使用经常是性能不佳的SQL引起的（或者这些SQL有可能用更少的资源完成同样的操作）；
对于这样的SQL，过多的IO操作也是一个症状。
关于CPU使用方面，我们会在之后讨论。
在以上基础上，我们将调查是否这个等待事件是有问题的。
若有问题，解决它；
若是正常的，检查下个等待事件。
过多的IO相关的等待一般会有两个主要的原因：
o数据库做了太多的读操作
o每次的IO读操作都很慢
Top5Events部分的显示的信息会帮助我们检查：
o是否数据库做了大量的读操作：
上面的图显示了在这段时间里两类读操作都分别大于1000万，这些操作是否过多取决于报告的时间是1小时或1分钟。
我们可以检查AWR报告的elapsedtime
如果这些读操作确实是太多了，接下来我们需要检查AWR报告中SQLStatistics部分的信息，因为读操作都是由SQL语句发起的。
o是否是每次的IO读操作都很慢：
上面的图显示了在这段时间里两类读操作平均的等待时间是小于8ms的
至于8ms是快还是慢取决于底层的硬件设备；
一般来讲小于20ms的都可以认为是可以接受的。
我们还可以在AWR报告"
TablespaceIOStats"
部分得到更详细的信息
oTablespaceIOStatsDB/Inst:
VMWREP/VMWREPSnaps:
1-15
o
o->
orderedbyIOs（Reads+Writes）desc
oTablespace
o------------------------------
oAvAvAvAvBufferAvBuf
oReadsReads/sRd（ms）Blks/RdWritesWrites/sWaitsWt（ms）
o----------------------------------------------------------------------
oTS_TX_DATA
o14,246,3672837.64.6145,263,8802,8833,844,1618.3
oUSER
o204,834410.71.017,849,02135415,2499.8
oUNDOTS1
o19,72503.01.010,064,0862001,9644.9
oAE_TS
o4,287,567855.46.79320465,7933.7
oTEMP
o2,022,883400.05.8878,0491700.0
oUNDOTS3
o1,310,493264.61.0941,67519430.0
oTS_TX_IDX
o1,884,478377.31.023,695073,7038.3
o>
SYSAUX
o346,09475.63.9112,744200.0
oSYSTEM
101,77127.93.525,09806532.7
如上图，我们关心AvRd（ms）的指标。
如果它高于20ms并且同时有很多读操作的，我们可能要开始从OS的角度调查是否有潜在的IO问题。
对于一些比较空闲的tablespace/files,我们可能会得到一个比较大的AvRd（ms）值；
对于这样的情况，我们应该忽略这样的tablespace/files;
因为这个很大的值可能是由于硬盘自旋（spin）引起的，没有太大的参考意义。
比如对于一个有1000万次读操作而且很慢的系统，引起问题的基本不可能是一个只有10次read的tablespace/file
以下的文档可以帮助我们进一步调查IO方面的问题：
Note:
223117.1TroubleshootingI/O-relatedwaits
虽然高"
和"
等待可以是I/O相关的问题，但是很多时候这些等待也可能是正常的；
实际上，对一个已经性能很好的数据库系统，这些等待事件往往在top5待事件里，因为这意味着您的数据库没有那些真正的“问题”。
诀窍是能够评估引起这些等待的语句是否使用了最优的访问路径。
如果"
比较高，那么相关的SQL语句可能使用了全表扫描而没有使用索引（也许是没有创建索引，也许是没有合适的索引）；
相应的，如果"
过多，则表明也许是这些SQL语句使用了selectivity不高的索引从而导致访问了过多不必要的索引块或者使用了错误的索引。
这些等待可能说明SQL语句的执行计划不是最优的。
接下来就需要通过AWR来检查这些topSQL是否可以进一步的调优，我们可以查看AWR报告中SQLStatistics的部分.
上面的例子显示了20%的时间花在了等待或者使用CPU上，我们也需要检查SQLstatistics部分来进一步的分析。
需要注意，接下来的分析步骤取决于我们在TOP5部分的发现。
在上面的例子里，3个topwaitevent表明问题可能与SQL语句执行计划不好有关，所以接下来我们要去分析"
SQLStatistics"
部分。
同样的，因为我们并没有看到latch相关的等待，latch在我们这个例子里并没有引发严重的性能问题；
那么我们接下来就完全不需要分析latch相关的信息。
一般来讲，如果数据库性能很慢，TOP5等待事件里"
CPU"
，"
和"
比较明显（不管它们之间的顺序如何），我们总是需要检查TopSQL（bylogicalandphysicalreads）部分；
调用SQLTuningAdvisor或者手工调优这些SQL来确保它们是有效率的运行。
∙SQLStatistics
AWR包含了一些不同的SQL统计值：
根据Top5部分的TopWaitEvent不同，我们需要检查不同的SQLstatistic。
在我们这个例子里，TopWaitEvent是"
，"
和CPU；
我们最需要关心的是SQLorderedbyCPUTime,GetsandReads。
我们会从"
SQLorderedbygets"
入手，因为引起高buffergets的SQL语句一般是需要调优的对象。
SQLorderedbyGets
->
ResourcesreportedforPL/SQLcodeincludestheresourcesusedbyallSQL
statementscalledbythecode.
TotalBufferGets:
4,745,943,815
CapturedSQLaccountfor122.2%ofTotal
GetsCPUElapsed
BufferGetsExecutionsperExec%TotalTime（s）Time（s）SQLId
--------------------------------------------------------------------------
1,228,753,8771687,314,011.225.98022.468404.735t1y1nvmwp2
SELECTADDRESSID"
CURRENT$."
ADDRESSTYPEID"
CURRENT$URRENT$."
ADDRESS3"
CURRENT$."
CITY"
ZIP"
STATE"
PHONECOUNTRYCODE"
PHONENUMBER"
PHONEEXTENSION"
FAXCOU
1,039,875,75962,959,36316.521.95320.275618.96grr4mg7ms81
Module:
DBMS_SCHEDULER
INSERTINTO"
ADDRESS_RDONLY"
（"
ADDRESSID"
"
CUSTOMERID"
ADDRESS1"
ADDRESS2"
PHONENU
854,035,2231685,083,543.018.05713.507458.954at7cbx8hnz
SELECT"
ISACTIVE"
FIRSTNAME"
LASTNAME"
CU<
RRENT$."
ORGANIZATION"
DATEREGISTERED"
CUSTOMERSTATUSID"
CURR
ENT$."
LASTMODIFIEDDATE"
SOURCE"
EMPLOYEEDEPT"
CURRENT$.
对这些TopSQL,可以手工调优，也可以调用SQLTuningAdvisor。
参照以下文档：
Document271196.1AutomaticSQLTuning-SQLProfiles.
Document262687.1HowtousetheSqlTuningAdvisor.
Document276103.1PERFORMANCETUNINGUSINGADVISORSANDMANAGEABILITYFEATURES:
AWR,ASH,andADDMandSqlTuningAdvisor.
注:
使用SQLTuningAdvisor需要额外的OracleTuningPackLicense:
假设这是一个一个小时的AWR报告，4,745,943,815是一个很大的值；
所以需要进一步分析这个SQL是否使用了最优的执行计划
oIndividualBufferGets
上面的例子里单个的SQL的bufferget非常多，最少的那个都是8亿5千万。
这三个SQL指向了两个不同的引起过多buffers的原因：
▪单次执行buffergets过多
SQL_ID为'
5t1y1nvmwp2'
和'
4at7cbx8hnz'
的SQL语句总共被执行了168次，但是每次执行引起的buffergets超过500万。
这两个SQL应该是主要的需要调优的候选者。
▪执行次数过多
SQL_ID'
grr4mg7ms81'
每次执行只是引起16次buffergets,减少这条SQL每次执行的bufferget可能并不能显著减少总共的buffergets。
这条语句的问题是它执行的太频繁了，6500万次。
改变这条SQL的执行次数可能会更有意义。
这个SQL看起来是在一个循环里面被调用，如果可以让它一次处理的数据更多也许可以减少它执行的次数。
注意：
对于某些非常繁忙的系统来讲，以上的数字可能都是正常的。
这时候我们需要把这些数字跟正常时段的数字作对比，如果没有什么太大差别，那么这些SQL并不是引起问题的元凶（虽然通过调优这些SQL我们仍然可以受益）
就像之前提到的那样，AWR报告中有很多不同的部分用来分析各种不同的问题。
如果特定的问题并没有出现，那么分析AWR报告的这些部分并不能有很大的帮助。
下面提到了一些可能的问题：
oWaitsfor'
如果发现了一些像"
pinSwaitonX"
或"
mutexX"
类的mutex等待，那么可能是由于parsing引起的问题。
检查"
SQLorderedbyParseCalls"
SQLorderedbyVersionCount"
部分的TopSQL，这些SQL可能引起这类的问题。
以下文档可以帮助我们分析这类问题：
Document1356828.1FAQ:
'
cursor:
mutex..'
/'
pin..'
librarycache:
TypeWaitEvents
1349387.1Troubleshooting'
pinSwaitonX'
waits.
∙LoadProfile
根据Top5等待事件的不同，"
LoadProfile"
可以提供一些有用的背景资料或潜在问题的细节信息。
~~~~~~~~~~~~PerSecondPerTransaction
------------------------------
Redosize:
4,585,414.803,165,883.14
Logicalreads:
94,185.6365,028.07
Blockchanges:
40,028.5727,636.71
Physicalreads:
2,206.121,523.16
Physicalwrites:
3,939.972,720.25
Usercalls:
50.0834.58
Parses:
26.9618.61
Hardparses:
1.491.03
Sorts:
18.3612.68
Logons:
0.130.09
Executes:
4,925.893,400.96
Transactions:
1.45
%BlockschangedperRead:
42.50RecursiveCall%:
99.19
Rollbackpertransaction%:
59.69RowsperSort:
1922.64
在这个例子里，Top5Events部分显示问题可能跟SQL的执行有关，那么我们接下来检查loadprofile部分。
如果您检查AWRreport是为了一般性的性能调优，那么可以看到有比较多的redoactivity和比较高的physicalwrites.Physicalwrites比physicalread要高，并且有42%的块被更改了.
此外，hardparse的次数要少于softparse.
如果mutex等待事件比较严重，如"
，那么查看所有parse的比率会更有用。
当然，如果把LoadProfile部分跟正常时候的AWR报告做比较会更有用，比如，比较redosize,userscalls,和parsing这些性能指标。
∙InstanceEfficiency
InstanceEfficiency部分更适用于一般性的调优，而不是解决某个具体问题（除非等待事件直接指向这些指标）。
InstanceEfficiencyPercentages（Target100%）
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BufferNowait%:
99.91RedoNoWait%:
100.00
BufferHit%:
98.14In-memorySort%:
9
升级会员 