oracle的awr报告分析.docxVIP

oracle的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个核:/sbinbindprocessor-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：每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的block数。LogicalReads=ConsistentGets+DBBlockGetsBlockchanges：每秒/每事务修改的块数Physicalreads：每秒/每事务物理读的块数Physicalwrites：每秒/每事务物理写的块数Usercalls：每秒/每事务用户call次数　　Parses：SQL解析的次数.每秒解析次数，包括fastparse，softparse和hardparse三种数量的综合。软解析每秒超过300次意味着你的应用程序效率不高，调整session_cursor_cache。在这里，fastparse指的是直接在PGA中命中的情况；softparse是指在sharedpool中命中的情形；hardparse则是指都不命中的情况。　　Hardparses：其中硬解析的次数，硬解析太多，说明SQL重用率不高。每秒产生的硬解析次数,每秒超过100次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force，该参数默认值为exact。但该参数设置为similar时，存在bug，可能导致执行计划的不