OracleAWR报告分析实例讲解.docx

资源描述

OracleAWR报告分析实例讲解.docx

《OracleAWR报告分析实例讲解.docx》由会员分享，可在线阅读，更多相关《OracleAWR报告分析实例讲解.docx（88页珍藏版）》请在冰豆网上搜索。

OracleAWR报告分析实例讲解.docx

OracleAWR报告分析实例讲解

WORKLOADREPOSITORYreportfor

DBName

DBId

Instance

Instnum

Release

RAC

Host

ICCI

1314098396

ICCI1

10.2.0.3.0

YES

HPGICCI1

SnapId

SnapTime

Sessions

Cursors/Session

BeginSnap:

2678

25-Dec-0814:

04:

1.5

EndSnap:

2680

25-Dec-0815:

23:

1.5

Elapsed:

78.79（mins）

DBTime:

11.05（mins）

Elapsed表示整个AWR报表统计的时间长度

DBTime是记录在服务器花在数据库运算（非后台进程）和等待（非空闲等待）上的时间

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:

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%:

100.00

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

Begin

End

MemoryUsage%:

47.19

47.50

%SQLwithexecutions>1:

88.48

79.81

%MemoryforSQLw/exec>1:

79.99

73.52

MemoryUsage%：

表示共享池内存使用率，对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明SharedPool有浪费，而如果高于90，说明共享池中有争用，内存不足。

SQLwithexecutions>1：

执行次数大于1的sql比率，如果此值太小的话要结合Parse，看看是不是硬编码现象，说明需要在应用中更多使用绑定变量，避免过多SQL解析。

MemoryforSQLw/exec>1：

执行次数大于1的SQL消耗内存的占比。

Top5TimedEvents

Event

Waits

Time（s）

AvgWait（ms）

%TotalCallTime

WaitClass

CPUtime

515

77.6

SQL*Netmoredatafromclient

27,319

9.7

Network

logfileparallelwrite

5,497

7.1

SystemI/O

dbfilesequentialread

7,900

5.3

UserI/O

dbfileparallelwrite

4,806

5.1

SystemI/O

这是报告概要的最后一节，显示了系统中最严重的5个等待，按所占等待时间的比例倒序列示。

当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。

例如如果‘bufferbusywait’是较严重的等待事件，我们应当继续研究报告中BufferWait和File/TablespaceIO区的内容，识别哪些文件导致了问题。

如果最严重的等待事件是I/O事件，我们应当研究按物理读排序的SQL语句区以识别哪些语句在执行大量I/O，并研究Tablespace和I/O区观察较慢响应时间的文件。

如果有较高的LATCH等待，就需要察看详细的LATCH统计识别哪些LATCH产生的问题。

在这里，logfileparallelwrite是相对比较多的等待，占用了7%的CPU时间。

通常，在没有问题的数据库中，CPUtime总是列在第一个。

更多的等待事件，参见本报告的WaitEvents一节。

RACStatistics

Begin

End

NumberofInstances:

GlobalCacheLoadProfile

PerSecond

PerTransaction

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）:

0.0

Avgglobalcachecrblocksendtime（ms）:

0.0

Globalcachelogflushesforcrblocksserved%:

3.5

Avgglobalcachecrblockflushtime（ms）:

3.9

Avgglobalcachecurrentblockpintime（ms）:

0.0

Avgglobalcachecurrentblocksendtime（ms）:

0.0

Globalcachelogflushesforcurrentblocksserved%:

0.4

Avgglobalcachecurrentblockflushtime（ms）:

3.0

GlobalCacheandEnqueueServices-MessagingStatistics

Avgmessagesentqueuetime（ms）:

0.0

Avgmessagesentqueuetimeonksxp（ms）:

0.3

Avgmessagereceivedqueuetime（ms）:

0.5

AvgGCSmessageprocesstime（ms）:

0.0

AvgGESmessageprocesstime（ms）:

0.0

%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

0.05

connectionmanagementcallelapsedtime

0.08

0.01

hardparse（sharingcriteria）elapsedtim

展开阅读全文