OracleAWR报告分析实例讲解Word下载.docx
《OracleAWR报告分析实例讲解Word下载.docx》由会员分享,可在线阅读,更多相关《OracleAWR报告分析实例讲解Word下载.docx(88页珍藏版)》请在冰豆网上搜索。
DBTime=cputime+waittime(不包含空闲等待)(非后台进程)
DBTime不包括Oracle后台进程消耗的时间。
如果DBTime远远小于Elapsed时间,说明数据库比较空闲。
上述报表中
Snapshot时间间隔约为79分钟,cpu就公有8*79=632分钟。
DBTime为11.05分钟,则:
cpu花费了11.05分钟在处理oracle非空闲等待和运算上(比如逻辑读),也就是说cpu有11.05/632=0.017%花费在处理oracle的操作上。
从awrreport的Elapsedtime和DBTime就能大概了解db的负载,计算公式可参考为:
cpu负载=DBTime/(cpu数*Elapsed)*100%
在79分钟里(其间收集了3次快照数据),数据库耗时11分钟,RDA数据中显示系统有8个逻辑CPU(4个物理CPU),平均每个CPU耗时1.4分钟,CPU利用率只有大约2%(1.4/79)。
说明系统压力非常小。
可是对于批量系统,数据库的工作负载总是集中在一段时间内。
如果快照周期不在这一段时间内,或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的。
这也说明选择分析时间段很关键,要选择能够代表性能问题的时间段。
ReportSummary
CacheSizes
Begin
End
BufferCache:
3,344M
StdBlockSize:
8K
SharedPoolSize:
704M
LogBuffer:
14,352K
显示SGA中每个区域的大小(在AMM改变它们之后),可用来与初始参数值比较。
sharedpool主要包括librarycache和dictionarycache。
librarycache用来存储最近解析(或编译)后SQL、PL/SQL和Javaclasses等。
librarycache用来存储最近引用的数据字典。
发生在librarycache或dictionarycache的cachemiss代价要比发生在buffercache的代价高得多。
因此sharedpool的设置要确保最近使用的数据都能被cache。
LoadProfile
PerSecond
PerTransaction
DBTime(s)
2.4
0.0
Redosize:
918,805.72
775,912.72
Logicalreads:
3,521.77
2,974.06
Blockchanges:
1,817.95
1,535.22
Physicalreads:
68.26
57.64
Physicalwrites:
362.59
306.20
Usercalls:
326.69
275.88
Parses:
38.66
32.65
Hardparses:
0.03
Sorts:
0.61
0.51
Logons:
0.01
Executes:
354.34
299.23
Transactions:
1.18
%BlockschangedperRead:
51.62
RecursiveCall%:
51.72
Rollbackpertransaction%:
85.49
RowsperSort:
########
显示数据库负载概况,将之与基线数据比较才具有更多的意义,如果每秒或每事务的负载变化不大,说明应用运行比较稳定。
单个的报告数据只说明应用的负载情况,绝大多数据并没有一个所谓“正确”的值,然而Logons大于每秒1~2个、Hardparses大于每秒100、全部parses超过每秒300表明可能有争用问题。
DBTime(s):
每秒内用于DB处理的时间,其他时间为等待时间
Redosize:
每秒/每事务产生的redo大小(单位字节),可标志数据库任务的繁重程序。
其中PerSecond表示每秒中产生的redo的字节数,PerTransaction表示每个事务产生的redo的字节数,可以通过后者可以看到事务的大小,协助判断是否commit次数太多。
例如persecond很大,而pertransaction很小,说明commit次数太多。
通常在很繁忙的系统中日志生成量可能达到上百k,甚至几百k。
Logicalreads:
每秒/每事务逻辑读的块数(我们可以这样认为,block在内存中,我们每一次读一块内存,就相当于一次逻辑读),单位为块,在良好的OLTP环境中,Logicalreads/Executes不会超过50,一般只有10左右,如果该指标较大,表示语句可能不够优化,需要具体分析,在该示例中,3,521.77/354.34,那么在OLAP中呢?
Blockchanges:
每秒/每事务修改的块数,即每秒中多少个块发生变化
Physicalreads:
每秒/每事务物理读的块数,即每秒数据库从磁盘读取的块个数
Physicalwrites:
每秒/每事务物理写的块数,即每秒有多少个块接受了数据库写入数据。
Usercalls:
每秒/每事务用户call次数Usercalls/Executes基本代表每个语句的请求次数,Executes越接近Usercalls越好。
Parses:
每秒的SQL语句解析的次数,超过300即需要关注,可以考虑调整参数session_cursor_cache来改善解析次数过高的现象。
Hardparses:
其中硬解析的次数,如果硬解析次数太高,说明SQL重用率不高。
例如超过100,基本都是由于不使用bindvar所导致的,导致cpu使用率的问题,极有使得性能急剧下降。
Sorts:
每秒/每事务的排序次数
Logons:
每秒/每事务登录的次数
Executes:
每秒/每事务SQL执行次数,包括用户执行的sql语句与系统执行的sql语句,表示一个系统sql的繁忙程度。
Transactions:
每秒产生的事物个数,反映数据库负载程度,不同的系统,略有差异,在典型的交易系统中,事务较多,而网站系统,可能select查询较多。
BlockschangedperRead:
表示逻辑读用于修改数据块的比例
RecursiveCall:
递归调用占所有操作的比率
Rollbackpertransaction:
每事务的回滚率
Rollbacks:
表示数据库中事务的回退率,如果不是因为业务本身的原因,通常应该小于10%为好,回退是一个很消耗资源的操作。
RowsperSort:
每次排序的行数
注:
Oracle的硬解析和软解析
提到软解析(softparse)和硬解析(hardparse),就不能不说一下Oracle对sql的处理过程。
当你发出一条sql语句交付Oracle,在执行和获取结果前,Oracle对此sql将进行几个步骤的处理过程:
1、语法检查(syntaxcheck)
检查此sql的拼写是否语法。
2、语义检查(semanticcheck)
诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。
3、对sql语句进行解析(parse)
利用内部算法对sql进行解析,生成解析树(parsetree)及执行计划(executionplan)。
4、执行sql,返回结果(executeandreturn)
其中,软、硬解析就发生在第三个过程里。
Oracle利用内部的hash算法来取得该sql的hash值,然后在librarycache里查找是否存在该hash值;
假设存在,则将此sql与cache中的进行比较;
假设“相同”,就将利用已有的解析树与执行计划,而省略了优化器的相关工作。
这也就是软解析的过程。
诚然,如果上面的2个假设中任有一个不成立,那么优化器都将进行创建解析树、生成执行计划的动作。
这个过程就叫硬解析。
创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作,所以,应当极力避免硬解析,尽量使用软解析。
InstanceEfficiencyPercentages(Target100%)
BufferNowait%:
100.00
RedoNoWait%:
BufferHit%:
98.72
In-memorySort%:
99.86
LibraryHit%:
99.97
SoftParse%:
99.92
ExecutetoParse%:
89.09
LatchHit%:
99.99
ParseCPUtoParseElapsd%:
7.99
%Non-ParseCPU:
99.95
本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。
其中BufferHitRatio也称CacheHitRatio,LibraryHitratio也称LibraryCacheHitratio。
同LoadProfile一节相同,这一节也没有所谓“正确”的值,而只能根据应用的特点判断是否合适。
在一个使用直接读执行大型并行查询的DSS环境,20%的BufferHitRatio是可以接受的,而这个值对于一个OLTP系统是完全不能接受的。
根据Oracle的经验,对于OLTPT系统,BufferHitRatio理想应该在90%以上。
BufferNowait%表示在数据缓冲区中获取的buffer时,未进行等待的比率,越高越好。
bufferhit%表示进程从内存中找到数据块的比率,监视这个值是否发生重大变化比这个值本身更重要。
对于一般的OLTP系统,命中率通常在95@以上,如果此值低于80%,应该给数据库分配更多的内存,考虑加大db_cache_size。
在数据仓库OLAP环境中,数据缓冲命中率不是一个重要的指标,因为OLAP数据库主要是物理读,甚至是直接读,该命中率不可能高。
RedoNoWai%t表示在LOG缓冲区获得BUFFER的未等待比例。
如果太低(可参考90%阀值),考虑增加LOGBUFFER。
libraryhit%表示Oracle从LibraryCache中检索到一个解析过的SQL或PL/SQL语句的比率,当应用程序调用SQL或存储过程时,Oracle检查LibraryCache确定是否存在解析过的版本,如果存在,Oracle立即执行语句;
如果不存在,Oracle解析此语句,并在LibraryCache中为它分配共享SQL区。
低的libraryhitratio会导致过多的解析,增加CPU消耗,降低性能。
Sql语句在库缓冲中能否找到相应的解析计划,如果libraryhitratio低于90%,可能需要调大sharedpool区,或检查是否有硬编码现象。
LatchHit%:
Latch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可,表示内部结构维护锁命中率。
要确保LatchHit>
99%,否则意味着SharedPoollatch争用,可能由于未共享的SQL,或者LibraryCache太小,可使用绑定变更或调大SharedPool解决。
ParseCPUtoParseElapsd:
表示解析实际运行时间/(解析实际运行时间+解析中等待资源时间),越高越好。
在实际繁忙的系统中,该值可能因为等待资源而不会太高。
Non-ParseCPU:
SQL实际运行时间/(SQL实际运行时间+SQL解析时间),太低表示解析消耗时间过多。
说明解析时间所占比率过高,需要考虑提高sql语句重用性。
ExecutetoParse:
是语句执行与分析的比例,表示sql语句解析后被重复执行的命中率,计算公式=100*(1-Parses/Executions),如果该值偏小,说明分析(硬分析和软分析)的比例较大,快速分析较少,根据实际情况,可以考虑调整session_cached_cursors参数,有些报告中这个值是负的,看上去很奇怪,事实上这表示一个问题,sql如果被ageout的话就可能出现这种情况,也就是sql老化,执行altersystemflushshared_pool
如果要SQL重用率高,则这个比例会很高。
该值越高表示一次解析后被重复执行的次数越多。
SoftParse%:
SQL语句软解析占整个分析的命中率,如果低于95,需检查是否有硬编码现象,如果低于80,说明sql语句基本没有重用性=soft/(soft+hard)
In-memorySort:
在内存中排序的比率,即有多少排序在内存中进行的,如果过低说明有大量的排序在临时表空间中进行,性能肯定不好,考虑调大PGA参数,sort_area_size。
SoftParse:
软解析的百分比(softs/softs+hards),近似当作sql在共享区的命中率,太低则需要调整应用使用绑定变量。
SharedPoolStatistics
MemoryUsage%:
47.19
47.50
%SQLwithexecutions>
1:
88.48
79.81
%MemoryforSQLw/exec>
79.99
73.52
MemoryUsage%:
表示共享池内存使用率,对于一个已经运行一段时间的数据库来说,共享池内存使用率,应该稳定在75%-90%间,如果太小,说明SharedPool有浪费,而如果高于90,说明共享池中有争用,内存不足。
SQLwithexecutions>
1:
执行次数大于1的sql比率,如果此值太小的话要结合Parse,看看是不是硬编码现象,说明需要在应用中更多使用绑定变量,避免过多SQL解析。
MemoryforSQLw/exec>
执行次数大于1的SQL消耗内存的占比。
Top5TimedEvents
Event
Waits
Time(s)
AvgWait(ms)
%TotalCallTime
WaitClass
CPUtime
515
77.6
SQL*Netmoredatafromclient
27,319
64
2
9.7
Network
logfileparallelwrite
5,497
47
9
7.1
SystemI/O
dbfilesequentialread
7,900
35
4
5.3
UserI/O
dbfileparallelwrite
4,806
34
7
5.1
这是报告概要的最后一节,显示了系统中最严重的5个等待,按所占等待时间的比例倒序列示。
当我们调优时,总希望观察到最显著的效果,因此应当从这里入手确定我们下一步做什么。
例如如果‘bufferbusywait’是较严重的等待事件,我们应当继续研究报告中BufferWait和File/TablespaceIO区的内容,识别哪些文件导致了问题。
如果最严重的等待事件是I/O事件,我们应当研究按物理读排序的SQL语句区以识别哪些语句在执行大量I/O,并研究Tablespace和I/O区观察较慢响应时间的文件。
如果有较高的LATCH等待,就需要察看详细的LATCH统计识别哪些LATCH产生的问题。
在这里,logfileparallelwrite是相对比较多的等待,占用了7%的CPU时间。
通常,在没有问题的数据库中,CPUtime总是列在第一个。
更多的等待事件,参见本报告的WaitEvents一节。
RACStatistics
NumberofInstances:
GlobalCacheLoadProfile
GlobalCacheblocksreceived:
4.16
3.51
GlobalCacheblocksserved:
5.97
5.04
GCS/GESmessagesreceived:
408.47
344.95
GCS/GESmessagessent:
258.03
217.90
DBWRFusionwrites:
0.05
EstdInterconnecttraffic(KB)
211.16
GlobalCacheEfficiencyPercentages(Targetlocal+remote100%)
Bufferaccess-localcache%:
98.60
Bufferaccess-remotecache%:
0.12
Bufferaccess-disk%:
1.28
GlobalCacheandEnqueueServices-WorkloadCharacteristics
Avgglobalenqueuegettime(ms):
0.1
Avgglobalcachecrblockreceivetime(ms):
1.1
Avgglobalcachecurrentblockreceivetime(ms):
0.8
Avgglobalcachecrblockbuildtime(ms):
Avgglobalcachecrblocksendtime(ms):
Globalcachelogflushesforcrblocksserved%:
3.5
Avgglobalcachecrblockflushtime(ms):
3.9
Avgglobalcachecurrentblockpintime(ms):
Avgglobalcachecurrentblocksendtime(ms):
Globalcachelogflushesforcurrentblocksserved%:
0.4
Avgglobalcachecurrentblockflushtime(ms):
3.0
GlobalCacheandEnqueueServices-MessagingStatistics
Avgmessagesentqueuetime(ms):
Avgmessagesentqueuetimeonksxp(ms):
0.3
Avgmessagereceivedqueuetime(ms):
0.5
AvgGCSmessageprocesstime(ms):
AvgGESmessageprocesstime(ms):
%ofdirectsentmessages:
14.40
%ofindirectsentmessages:
77.04
%offlowcontrolledmessages:
8.56
MainReport
∙WaitEventsStatistics
∙SQLStatistics
∙InstanceActivityStatistics
∙IOStats
∙BufferPoolStatistics
∙AdvisoryStatistics
∙WaitStatistics
∙UndoStatistics
∙LatchStatistics
∙SegmentStatistics
∙DictionaryCacheStatistics
∙LibraryCacheStatistics
∙MemoryStatistics
∙StreamsStatistics
∙ResourceLimitStatistics
∙init.oraParameters
WaitEventsStatistics
∙TimeModelStatistics
∙WaitClass
∙WaitEvents
∙BackgroundWaitEvents
∙OperatingSystemStatistics
∙ServiceStatistics
∙ServiceWaitClassStats
BacktoTop
TimeModelStatistics
∙Totaltimeindatabaseuser-calls(DBTime):
663s
∙Statisticsincludingtheword"
background"
measurebackgroundprocesstime,andsodonotcontributetotheDBtimestatistic
∙Orderedby%orDBtimedesc,Statisticname
StatisticName
Time(s)
%ofDBTime
DBCPU
514.50
77.61
sqlexecuteelapsedtime
482.27
72.74
parsetimeelapsed
3.76
0.57
PL/SQLexecutionelapsedtime
0.50
0.08
hardparseelapsedtime
0.34
connectionmanagementcallelapsedtime
hardparse(sharingcriteria)elapsedtim