OracleAWR教你如何看.docx
《OracleAWR教你如何看.docx》由会员分享，可在线阅读，更多相关《OracleAWR教你如何看.docx（92页珍藏版）》请在冰豆网上搜索。
OracleAWR教你如何看
/u01/ora10g/db_1/rdbms/admin
可直接执行即可
1.查看当前的AWR保存策略
select*fromdba_hist_wr_control;
DBID,SNAP_INTERVAL,RETENTION,TOPNSQL
9,+0001:
00:
+0700:
00:
DEFAULT
以上结果表示,每小时产生一个SNAPSHOT，保留7天
2.调整AWR配置
AWR配置都是通过dbms_workload_repository包进行配置
调整AWR产生snapshot的频率和保留策略，如：
如将收集间隔时间改为30分钟一次。
并且保留5天时间（注：
单位都是为分钟）：
exec（interval=>30,retention=>5*24*60）;
关闭AWR,把interval设为0则关闭自动捕捉快照
手工创建一个快照
exec（）;
查看快照
select*from$_active_session_history
手工删除指定范围的快照
exec（low_snap_id=>22,high_snap_id=>32,dbid=>47）;
创建baseline
exec（56,59,'apply_interest_1'）
删除baseline
exec（baseline_name=>'apply_interest_1',cascade=>FALSE）;
3.生产AWR报告
$ORACLE_HOME/rdbms/admin/
WORKLOADREPOSITORYreportfor
DBId
Instance
Instnum
Release
RAC
Host
ICCI
96
ICCI1
1
10.2.0.
YES
HPGICCI1
SnapId
SnapTime
Sessions
Cursors/Session
BeginSnap:
2678
25-Dec-0814:
04:
50
24
EndSnap:
2680
25-Dec-0815:
23:
37
26
Elapsed:
（mins）
DBTime:
（mins）
DBTime不包括Oracle后台进程消耗的时间。
如果DBTime远远小于Elapsed时间，说明数据库比较空闲。
在79分钟里（其间收集了3次快照数据），数据库耗时11分钟，RDA数据中显示系统有8个逻辑CPU（4个物理CPU），平均每个CPU耗时分钟，CPU利用率只有大约2%（79）。
说明系统压力非常小。
可是对于批量系统，数据库的工作负载总是集中在一段时间内。
如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。
这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。
ReportSummary
CacheSizes
Begin
End
BufferCache:
3,344M
3,344M
StdBlockSize:
8K
SharedPoolSize:
704M
704M
LogBuffer:
14,352K
显示SGA中每个区域的大小（在AMM改变它们之后），可用来与初始参数值比较。
sharedpool主要包括librarycache和dictionarycache。
librarycache用来存储最近解析（或编译）后SQL、PL/SQL和Javaclasses等。
librarycache用来存储最近引用的数据字典。
发生在librarycache或dictionarycache的cachemiss代价要比发生在buffercache的代价高得多。
因此sharedpool的设置要确保最近使用的数据都能被cache。
LoadProfile
PerSecond
PerTransaction
Redosize:
918,
775,
Logicalreads:
3,
2,
Blockchanges:
1,
1,
Physicalreads:
Physicalwrites:
Usercalls:
Parses:
Hardparses:
Sorts:
Logons:
Executes:
Transactions:
%BlockschangedperRead:
RecursiveCall%:
Rollbackpertransaction%:
RowsperSort:
########
显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。
单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而Logons大于每秒1~2个、Hardparses大于每秒100、全部parses超过每秒300表明可能有争用问题。
Redosize：
每秒/每事务产生的redo大小（单位字节），可标志数据库任务的繁重程序。
Logicalreads：
每秒/每事务逻辑读的块数
Blockchanges：
每秒/每事务修改的块数
Physicalreads：
每秒/每事务物理读的块数
Physicalwrites：
每秒/每事务物理写的块数
Usercalls：
每秒/每事务用户call次数
Parses：
SQL解析的次数
Hardparses：
其中硬解析的次数，硬解析太多，说明SQL重用率不高。
Sorts：
每秒/每事务的排序次数
Logons：
每秒/每事务登录的次数
Executes：
每秒/每事务SQL执行次数
Transactions：
每秒事务数
BlockschangedperRead：
表示逻辑读用于修改数据块的比例
RecursiveCall：
递归调用占所有操作的比率
Rollbackpertransaction：
每事务的回滚率
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%:
RedoNoWait%:
BufferHit%:
In-memorySort%:
LibraryHit%:
SoftParse%:
ExecutetoParse%:
LatchHit%:
ParseCPUtoParseElapsd%:
%Non-ParseCPU:
本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。
其中BufferHitRatio也称CacheHitRatio，LibraryHitratio也称LibraryCacheHitratio。
同LoadProfile一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。
在一个使用直接读执行大型并行查询的DSS环境，20%的BufferHitRatio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。
根据Oracle的经验，对于OLTPT系统，BufferHitRatio理想应该在90%以上。
BufferNowait表示在内存获得数据的未等待比例。
bufferhit表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。
对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存。
RedoNoWait表示在LOG缓冲区获得BUFFER的未等待比例。
如果太低（可参考90%阀值），考虑增加LOGBUFFER。
libraryhit表示Oracle从LibraryCache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查LibraryCache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在LibraryCache中为它分配共享SQL区。
低的libraryhitratio会导致过多的解析，增加CPU消耗，降低性能。
如果libraryhitratio低于90%，可能需要调大sharedpool区。
LatchHit：
Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。
要确保LatchHit>99%，否则意味着SharedPoollatch争用，可能由于未共享的SQL，或者LibraryCache太小，可使用绑定变更或调大SharedPool解决。
ParseCPUtoParseElapsd：
解析实际运行时间/（解析实际运行时间+解析中等待资源时间），越高越好。
Non-ParseCPU：
SQL实际运行时间/（SQL实际运行时间+SQL解析时间），太低表示解析消耗时间过多。
ExecutetoParse：
是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。
该值越高表示一次解析后被重复执行的次数越多。
In-memorySort：
在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。
考虑调大PGA。
SoftParse：
软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。
SharedPoolStatistics
Begin
End
MemoryUsage%:
%SQLwithexecutions>1:
%MemoryforSQLw/exec>1:
MemoryUsage%：
对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明SharedPool有浪费，而如果高于90，说明共享池中有争用，内存不足。
SQLwithexecutions>1：
执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。
MemoryforSQLw/exec>1：
执行次数大于1的SQL消耗内存的占比。
Top5TimedEvents
Event
Waits
Time（s）
AvgWait（ms）
%TotalCallTime
WaitClass
CPUtime
515
SQL*Netmoredatafromclient
27,319
64
2
Network
logfileparallelwrite
5,497
47
9
SystemI/O
dbfilesequentialread
7,900
35
4
UserI/O
dbfileparallelwrite
4,806
34
7
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:
2
2
GlobalCacheLoadProfile
PerSecond
PerTransaction
GlobalCacheblocksreceived:
GlobalCacheblocksserved:
GCS/GESmessagesreceived:
GCS/GESmessagessent:
DBWRFusionwrites:
EstdInterconnecttraffic（KB）
GlobalCacheEfficiencyPercentages（Targetlocal+remote100%）
Bufferaccess-localcache%:
Bufferaccess-remotecache%:
Bufferaccess-disk%:
GlobalCacheandEnqueueServices-WorkloadCharacteristics
Avgglobalenqueuegettime（ms）:
Avgglobalcachecrblockreceivetime（ms）:
Avgglobalcachecurrentblockreceivetime（ms）:
Avgglobalcachecrblockbuildtime（ms）:
Avgglobalcachecrblocksendtime（ms）:
Globalcachelogflushesforcrblocksserved%:
Avgglobalcachecrblockflushtime（ms）:
Avgglobalcachecurrentblockpintime（ms）:
Avgglobalcachecurrentblocksendtime（ms）:
Globalcachelogflushesforcurrentblocksserved%:
Avgglobalcachecurrentblockflushtime（ms）:
GlobalCacheandEnqueueServices-MessagingStatistics
Avgmessagesentqueuetime（ms）:
Avgmessagesentqueuetimeonksxp（ms）:
Avgmessagereceivedqueuetime（ms）:
AvgGCSmessageprocesstime（ms）:
AvgGESmessageprocesstime（ms）:
%ofdirectsentmessages:
%ofindirectsentmessages:
%offlowcontrolledmessages:
MainReport
WaitEventsStatistics
SQLStatistics
InstanceActivityStatistics
IOStats
BufferPoolStatistics
AdvisoryStatistics
WaitStatistics
UndoStatistics
LatchStatistics
SegmentStatistics
DictionaryCacheStatistics
LibraryCacheStatistics
MemoryStatistics
StreamsStatistics
ResourceLimitStatistics
Parameters
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
sqlexecuteelapsedtime
parsetimeelapsed
PL/SQLexecutionelapsedtime
hardparseelapsedtime
connectionmanagementcallelapsedtime
hardparse（sharingcriteria）elapsedtime
repeatedbindelapsedtime
PL/SQLcompilationelapsedtime
failedparseelapsedtime
DBtime
backgroundelapsedtime
backgroundcputime
此节显示了各种类型的数据库处理任务所占用的CPU时间。
BacktoWaitEventsStatistics
BacktoTop
WaitClass
s-second
cs-centisecond-100thofasecond
ms-millisecond-1000thofasecond
us-microsecond-1000000thofasecond
orderedbywaittimedesc,waitsdesc
WaitClass
Waits
%Time-outs
TotalWaitTime（s）
Avgwait（ms）
Waits/txn
UserI/O
66,837
120
2
SystemI/O
28,295
93
3
Network
1,571,450
66
0
Cluster
210,548
29
0
Other
81,783
28
0
Application
333,155
16
0
Concurrency
5,182
5
1
Commit
919
4
4
Configuration
25,427
1
0
BacktoWaitEventsStatistics
BacktoTop
WaitEvents
s-second
cs-centisecond-100thofasecond
ms-millisecond-1000thofasecond
us-microsecond-1000000thofasecond
orderedbywaittimedesc,waitsdesc（idleeventslast）
Event
Waits
%Time-outs
TotalWaitTime（s）
Avgwait（ms）
Waits/txn
SQL*Netmoredatafromclient
27,319
64
2
logfileparallelwrite
5,497
47
9
dbfilesequentialread
7,900
35
4
dbfileparallelwrite
4,806
34
7
dbfilescatteredread
10,310
31
3
directpathwrite
42,724
30
1
reliablemessage
355
18
49
SQL*Netbreak/resettoclient
333,084
16
0
dbfile
升级会员 