文档介绍：11g,awr报告详细分析 Elapsed时间,说明数据库比较空闲。 dbtime=cputime+waittime 说白了就是dbtime就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间 DBtime=cputime+allofnonidlewaiteventtime 在79分钟里,数据库耗时11分钟,RDA数据中显示系统有8个逻辑CPU,平均每个CPU耗时分钟,CPU利用率只有大约2%。说明系统压力非常小。列出下面这两个来做解释:ReportA: SnapIdSnapTimeSessionsCurs/Sess--------------------------------------------- BeginSnap:-Jul-0822:00:5468EndSnap:-Jul-0823:00:2517Elapsed:(mins)DBTime:(mins) ReportB: SnapIdSnapTimeSessionsCurs/Sess--------------------------------------------- BeginSnap:-Nov-0721:00:3739EndSnap:-Nov-0722:00:1540Elapsed:(mins)DBTime:(mins) 服务器是AIX的系统,4个双核cpu,共8个核:/sbin>bindprocessor-q Theavailableprocessorsare: 先说ReportA,在snapshot间隔中,总共约60分钟,cpu就共有60*8=480分钟,DBtime为分钟,则: cpu花费了分钟在处理Oralce非空闲等待和运算上(比方逻辑读) 也就是说cpu有/480*100%花费在处理Oracle的操作上,这还不包括后台进程看ReportB,总共约60分钟,cpu有/480*100%花费在处理Oracle的操作上很显然,2中服务器的平均负载很低。从awrreport的Elapsedtime和DBTime就能大概了解db的负载。可是对于批量系统,数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内,或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的。这也说明选择分析时间段很关键,要选择能够代表性能问题的时间段。 CacheSizes 值比较。 sharedpool主要包括librarycache和dictionarycache。librarycache用来存储最近解析后SQL、PL/SQL和Javaclasses等。librarycache用来存储最近引用的数据字典。发生在librarycache或dictionarycache的cachemiss代价要比发生在buffercache的代价高得多。因此sharedpool的设置要确保最近使用的数据都能被cache。 LoadProfile 事务的负载变化不大,说明应用运行比较稳定。单个的报告数据只说明应用的负载情况,绝大多数据并没有一个所谓“正确”的值,然而Logons大于每秒1~2个、Hardparses大于每秒100、全部parses超过每秒300表明可能有争用问题。 Redosize:每秒产生的日志大小(单位字节),可标志数据变更频率,数据库任务的繁重与否。Logicalreads:每秒/。LogicalReads=ConsistentGets+DBBlockGetsBlockchanges:每秒/每事务修改的块数Physicalreads:每秒/每事务物理读的块数Physicalwrites:每秒/每事务物理写的块数Usercalls:每秒/每事务用户call次数 Parses:,包括fastparse,softparse和hardparse三种数量的综合。软解析每秒超过300次意味着你的"应用程序"效率不高,调整session_cursor_cache。在这里,fastparse指的是直接在PGA中命中的情况;softparse是指在sharedpool中命中的情形;hardparse则是指都不命中的情况。 Hardparses:其中硬解析的次数,硬解析太多,说明SQL重用率不高。每秒产生的硬解析次数,每秒超过100次,就可能说明你绑定使用的不好,也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force,该参数默认值为exact。但该参数设置为similar时,存在bug,可能导致执行计划的不优。 Sorts:每秒/每事务的排序次数Logons:每秒/每事务登录的次数Executes:每秒/每事务SQL执行