awr报告分析工具.docxVIP

awr报告分析工具 　　Oracle10gAWR报告分析　　转自：http:///35489/viewspace-byElapsedTime：　　记录了执行总和时间的TOPSQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间ElapsedTime=CPUTime+WaitTime)。　　SQLorderedbyElapsedTime?ResourcesreportedforPL/SQLcodeincludestheresourcesusedbyallS　　QLstatementscalledbythecode.　　?%TotalDBTimeistheElapsedTimeoftheSQLstatementdivi(来自:写论文网:awr报告分析工具)dedintot　　heTotalDatabaseTimemultipliedby100　　ElapsedTime(S):SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。ElapsedTime=CPUTime+WaitTime　　CPUTime(s):为SQL语句执行时CPU占用时间总时长，此时间会小于等于ElapsedTime时间。单位时间为秒。　　Executions:SQL语句在监控范围内的执行次数总计。　　ElapperExec(s):执行一次SQL的平均时间。单位时间为秒。　　%TotalDBTime:为SQL的ElapsedTime时间占数据库总时间的百分比。　　SQLID:SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQLID的地方。　　SQLModule:显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。　　SQLText:简单的sql提示，详细的需要点击SQLID。　　orderedbyCPUTime:　　记录了执行占CPU时间总和时间最长的TOPSQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。　　orderedbyGets:　　记录了执行占总buffergets(逻辑IO)的TOPSQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets).　　orderedbyReads:　　记录了执行占总磁盘物理读(物理IO)的TOPSQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。　　orderedbyExecutions:　　记录了按照SQL的执行次数排序的TOPSQL。该排序可以看出监控范围内的SQL执行次数。　　orderedbyParseCalls:　　记录了SQL的软解析次数的TOPSQL。　　说到软解析(softprase)和硬解析(hardprase)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程：　　1、语法检查(syntaxcheck)　　检查此sql的拼写是否语法。　　2、语义检查(semanticcheck)　　诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。　　3、对sql语句进行解析(prase)　　利用内部算法对sql进行解析，生成解析树(parsetree)及执行计划(executionplan)。　　4、执行sql，返回结果(executeandreturn)　　其中，软、硬解析就发生在第三个过程里。　　Oracle利用内部的hash算法来取得该sql的hash值，然后在librarycache里查找是否存在该hash值；　　假设存在，则将此sql与cache中的进行比较；　　假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。　　诚然，如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。　　创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。这就是在很多项目中，倡导开发设计人员对功能相同的代码要努力保持代码的一致性，以及要在程序中多使用绑定变量的原因。　　/****************************************************/　　大家都在说在Sql中使用了Bin