《管理信息化ORACLEOracleAWR报告分析实例讲解》由会员分享，可在线阅读，更多相关《管理信息化ORACLEOracleAWR报告分析实例讲解（57页珍藏版）》请在金锄头文库上搜索。
1、管理信息化 ORACLEOracleAWR 报 告分析实例讲解 管理信息化 ORACLEOracleAWR 报 告分析实例讲解 WORKLOADREPOSITORYreportforWORKLOADREPOSITORYreportfor DBNameDBNameDBIdDBIdInstanceInstanceInstnumInstnumReleaseReleaseRACRACHostHost ICCI396ICCI1110.2.0.3.0YESHPGICCI1 SnapIdSnapIdSnapTimeSnapTimeSessionsSessionsCursors/SessionCursors/
2、Session BeginSnap:267825-Dec-0814:04:50241.5 EndSnap:268025-Dec-0815:23:37261.5 Elapsed:78.79(mins) DBTime:11.05(mins) DBTime 不包括 Oracle 后台进程消耗的时间。 如果 DBTime 远远小于 Elapsed 时 间，说明数据库比较空闲。 在 79 分钟里（其间收集了 3 次快照数据），数据库耗时 11 分钟，RDA 数据中 显示系统有 8 个逻辑 CPU（4 个物理 CPU），平均每个 CPU 耗时 1.4 分钟，CPU 利 用率只有大约 2%（1.4/79）。
3、说明系统压力非常小。 可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期 不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所 得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代 表性能问题的时间段。 ReportReportSummarySummary CacheSizesCacheSizes BeginBeginEndEnd BufferCache:3,344M3,344MStdBlockSize:8K SharedPoolSize:704M704MLogBuffer:14,352K 显示 SGA 中每个区域的大小（在 AMM 改变它
4、们之后），可用来与初始参数值比 较。 sharedpool 主要包括 librarycache 和 dictionarycache。librarycache 用来 存储最近解析（或编译） 后 SQL、PL/SQL 和 Javaclasses 等。librarycache 用来 存储最近引用的数据字典。发生在 librarycache 或 dictionarycache 的 cachemiss 代价要比发生在 buffercache 的代价高得多。 因此 sharedpool 的设置 要确保最近使用的数据都能被 cache。 LoadProfileLoadProfile PerSecondPer
5、SecondPerTransactionPerTransaction Redosize:918,805.72775,912.72 Logicalreads:3,521.772,974.06 Blockchanges:1,817.951,535.22 Physicalreads:68.2657.64 Physicalwrites:362.59306.20 Usercalls:326.69275.88 Parses:38.6632.65 Hardparses:0.030.03 Sorts:0.610.51 Logons:0.010.01 Executes:354.34299.23 Transact
6、ions:1.18 %BlockschangedperRead:51.62RecursiveCall%:51.72 Rollbackpertransaction%:85.49RowsperSort:# 显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每 事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负 载情况，绝大多数据并没有一个所谓“正确”的值，然而 Logons 大于每秒 12 个、Hardparses 大于每秒 100、全部 parses 超过每秒 300 表明可能有争用问题。 Redosize：每秒/每事务产生的 redo 大小（单位字节），可标
7、志数据库任务的 繁重程序。 Logicalreads：每秒/每事务逻辑读的块数 Blockchanges：每秒/每事务修改的块数 Physicalreads：每秒/每事务物理读的块数 Physicalwrites：每秒/每事务物理写的块数 Usercalls：每秒/每事务用户 call 次数 Parses：SQL 解析的次数 Hardparses：其中硬解析的次数，硬解析太多，说明 SQL 重用率不高。 Sorts：每秒/每事务的排序次数 Logons：每秒/每事务登录的次数 Executes：每秒/每事务 SQL 执行次数 Transactions：每秒事务数 Blockschangedpe
8、rRead：表示逻辑读用于修改数据块的比例 RecursiveCall：递归调用占所有操作的比率 Rollbackpertransaction：每事务的回滚率 RowsperSort：每次排序的行数 注: Oracle 的硬解析和软解析 提到软解析(softparse)和硬解析(hardparse)，就不能不说一下 Oracle 对 sql 的处理过程。当你发出一条 sql 语句交付 Oracle，在执行和获取结果前，Oracle 对此 sql 将进行几个步骤的处理过程： 1、语法检查(syntaxcheck) 检查此 sql 的拼写是否语法。 2、语义检查(semanticcheck) 诸如
9、检查 sql 语句中的访问对象是否存在及该用户是否具备相应的权限。 3、对 sql 语句进行解析(parse) 利 用 内 部 算 法 对 sql 进 行 解 析 ， 生 成 解 析 树 (parsetree) 及 执 行 计 划 (executionplan)。 4、执行 sql，返回结果(executeandreturn) 其中，软、硬解析就发生在第三个过程里。 Oracle 利用内部的 hash 算法来取得该 sql 的 hash 值，然后在 librarycache 里 查找是否存在该 hash 值； 假设存在，则将此 sql 与 cache 中的进行比较； 假设“相同” ，就将利用已
10、有的解析树与执行计划，而省略了优化器的相关工作。 这也就是软解析的过程。 诚然， 如果上面的 2 个假设中任有一个不成立， 那么优化器都将进行创建解析树、 生成执行计划的动作。这个过程就叫硬解析。 创建解析树、生成执行计划对于 sql 的执行来说是开销昂贵的动作，所以，应当 极力避免硬解析，尽量使用软解析。 InstanceEfficiencyPercentages(Target100%)InstanceEfficiencyPercentages(Target100%) BufferNowait%:100.00RedoNoWait%:100.00 BufferHit%:98.72In-memo
11、rySort%:99.86 LibraryHit%:99.97SoftParse%:99.92 ExecutetoParse%:89.09LatchHit%:99.99 ParseCPUtoParseElapsd%:7.99%Non-ParseCPU:99.95 本节包含了 Oracle 关键指标的内存命中率及其它数据库实例操作的效率。其 中 BufferHitRatio也 称 CacheHitRatio， LibraryHitratio也 称 LibraryCacheHitratio。同 LoadProfile 一节相同，这一节也没有所谓“正确” 的值，而只能根据应用的特点判断是否合适。在一
12、个使用直接读执行大型并行查 询的 DSS 环境，20%的 BufferHitRatio 是可以接受的，而这个值对于一个 OLTP 系统是完全不能接受的。根据 Oracle 的经验，对于 OLTPT 系统，BufferHitRatio 理想应该在 90%以上。 BufferNowait 表示在内存获得数据的未等待比例。 bufferhit 表示进程从内存中找到数据块的比率，监视这个值是否发生重大变 化比这个值本身更重要。对于一般的 OLTP 系统，如果此值低于 80%，应该给数据 库分配更多的内存。 RedoNoWait 表示在 LOG 缓冲区获得 BUFFER 的未等待比例。如果太低（可参考
13、90%阀值），考虑增加 LOGBUFFER。 libraryhit 表示 Oracle 从 LibraryCache 中检索到一个解析过的 SQL 或 PL/SQL 语句的比率，当应用程序调用 SQL 或存储过程时，Oracle 检查 LibraryCache 确定是否存在解析过的版本，如果存在，Oracle 立即执行语句； 如果不存在，Oracle 解析此语句，并在 LibraryCache 中为它分配共享 SQL 区。 低的 libraryhitratio 会导致过多的解析，增加 CPU 消耗，降低性能。如果 libraryhitratio 低于 90%，可能需要调大 sharedpool
14、 区。 LatchHit： Latch 是一种保护内存结构的锁，可以认为是 SERVER 进程获取访问 内存数据结构的许可。 要确保 LatchHit99%， 否则意味着 SharedPoollatch 争用， 可能由于未共享的 SQL，或者 LibraryCache 太小，可使用绑定变更或调大 SharedPool 解决。 ParseCPUtoParseElapsd：解析实际运行时间/(解析实际运行时间+解析中等待 资源时间)，越高越好。 Non-ParseCPU： SQL 实际运行时间/(SQL 实际运行时间+SQL 解析时间)，太低表 示解析消耗时间过多。 ExecutetoParse：
15、是语句执行与分析的比例，如果要 SQL 重用率高，则这个比 例会很高。该值越高表示一次解析后被重复执行的次数越多。 In-memorySort：在内存中排序的比率，如果过低说明有大量的排序在临时表 空间中进行。考虑调大 PGA。 SoftParse：软解析的百分比（softs/softs+hards），近似当作 sql 在共享区 的命中率，太低则需要调整应用使用绑定变量。 SharedPoolStatisticsSharedPoolStatistics BeginBeginEndEnd MemoryUsage%:47.1947.50 %SQLwithexecutions1:88.4879.81
16、 %MemoryforSQLw/exec1:79.9973.52 MemoryUsage%： 对于一个已经运行一段时间的数据库来说， 共享池内存使用率， 应该稳定在 75%-90%间，如果太小，说明 SharedPool 有浪费，而如果高于 90， 说明共享池中有争用，内存不足。 SQLwithexecutions1：执行次数大于 1 的 sql 比率，如果此值太小，说明需 要在应用中更多使用绑定变量，避免过多 SQL 解析。 MemoryforSQLw/exec1：执行次数大于 1 的 SQL 消耗内存的占比。 Top5TimedEventsTop5TimedEvents EventEventWaitsWaitsTime(s)Time(s)AvgWait(ms)AvgWait(ms)%TotalCallTime%TotalCallTimeWaitClassWaitClass CPUtime51577.6 SQL*Netmoredatafromclient27,3196429.7Network logfileparallelwrite5,4974797.1Sys
