最详尽的AWR报告详细分析

AWR报告详细分析AWR是Oracle版本中引入的新功能。它的全名是AutomaticWorkloadRepository-自动加载库。AWR通过比较两个快速快照收集的统计信息生成报告数据。生成的报告包括多个部分。工作负载存储库报告ICCI1314098396ICCI1110.2.0.3.0是HPGICCI1开始快照：26782008年12月25日14:04:50241.5末端卡扣：26802008年12月25日15:23:37261.5Elapsed:78.79(分钟)数据库时间：11.05(分钟)数据库时间不包括Oracle守护程序消耗的时间。如果数据库时间比运行时间短得多，则数据库处于空闲状态。Db时间=cpu时间等待时间(不包括空闲等待)(非后台进程)坦率地说，数据库时间是记录的服务器花费在数据库操作(非后台进程)和等待(非空闲等待)上的时间数据库时间=所有非等待事件的cpu时间在79分钟内(在此期间收集了3个快照数据)，数据库耗时11分钟，RDA数据显示系统有8个逻辑处理器(4个物理处理器)，每个处理器平均耗时1.4分钟，处理器利用率仅为2%(1.4/79)。这表明系统压力非常低。列举以下两个来解释：报告A:快照Id快照时间会话粗略/会话-开始快照： 4610 24-7月8 22:00336054 68 19.1结束快照： 4612 24-7月24-08 23:00336025 17 1.7延时： 59.51(分钟)数据库时间： 466.37(分钟)报告B:快照Id快照时间会话粗略/会话-开始快照： 3098 13-11月7 21:00:37 39 13.6结束快照： 3102 13-11月7 22:00:15 40 16.4延时： 59.63(分钟)数据库时间： 19.49(分钟)该服务器是一个AIX系统，具有4个双核cpu和总共8个内核：/sbin bindprocessor -q可用的处理器是： 0 1 2 3 4 5 6 7让我们从报告A开始。在总共约60分钟的快照间隔中，cpu的总时间为60*8=480分钟，数据库时间为466.37分钟，然后：cpu花了466.37分钟处理Oralce非空闲等待和操作(如逻辑读取)换句话说，466.37/480*100%的cpu用于Oracle操作，不包括后台进程看看报告B，总共大约60分钟，cpu有19.49/480*100%花费在Oracle操作上显然，2中服务器的平均负载非常低。从awr报告的运行时间和数据库时间可以大致了解数据库的负载。但是，对于批处理系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这段时间内，或者如果快照周期跨度太长并且包含大量数据库空闲时间，则获得的分析结果是没有意义的。这也表明，选择能够代表性能问题的分析时间段是非常重要的。报告摘要缓存大小缓冲区缓存：3，344米3，344米标准块尺寸：8K共享池大小：704M704M日志缓冲：14，352K显示SGA每个区域的大小(在AMM更改后)，并可用于与初始参数值进行比较。共享池主要包括库缓存和字典缓存。库缓存用于存储最近解析(或编译)的SQL、PL/SQL、Java类等。LibrarCache用于存储最近引用的数据字典。在库缓存或字典缓存中发生的缓存未命中成本比在缓冲区缓存中发生的成本高得多。因此，应该设置共享池，以确保最近使用的数据可以缓存。负载曲线重做大小：918，805.72775，912.72逻辑读取33603，521.772，974.06块改变33601，817.95英镑1，535.22物理读取336068.2657.64物理写入3360362.59306.20用户呼叫：326.69275.88解析器：38.6632.65硬解析器33600.030.03Sorts:0.610.51徽标：0.010.01执行：354.34299.23交易：1.18每次读取更改的块百分比：51.62递归调用336051.72每个事务回滚336085.49每批行数：#显示数据库的负载概况并将其与基线数据进行比较是有意义的。如果每秒或每个事务的负载变化很小，应用程序就会稳定运行。单一报告数据仅显示应用程序的负载情况，绝大多数数据没有所谓的“正确”值。但是，登录次数大于1-2次/秒，硬解析大于100次/秒，所有解析都大于300次/秒，这表明可能存在争用问题。重做大小：每秒生成的日志大小(单位字节)，它可以指示数据更改的频率以及数据库任务是否繁重。逻辑读取：每秒/事务的逻辑读取数。刷新每秒生成的逻辑读取数。逻辑读取=一致获取数据库块获取块更改：每秒修改的块数/事务物理读取：每秒物理读取的块数/事务物理写入：每秒物理写入的块数/事务用户呼叫：每秒/每次交易的用户呼叫数解析：每秒SQL解析的次数，包括快速解析、软解析和硬解析的组合。每秒超过300次的软解析意味着您的“应用程序”没有效率，请调整session_cursor_cache。在这种情况下，快速解析指的是在PGA中直接命中的情况(设置了会话缓存游标=n)；软解析指的是共享池中的命中；硬解析指的是没有人点击的情况。硬分析：硬分析的数量太高，这表明SQL重用率不高。每秒的硬解析次数(超过100次)可能表示您没有很好地使用绑定，或者共享池设置不合理。此时，可以启用参数cursor _ sharing=相似|force，并且该参数的默认值是精确的。但是，当此参数设置为相似时，会出现一个错误，这可能会导致执行计划不佳。排序：每秒排序/事务登录：每秒/事务的登录次数执行：每秒执行的SQL事务交易：每秒交易数。每秒生成的事务数反映了数据库任务是否繁重。每次读取更改的块：指示用于修改数据块的逻辑读取的比例。每次逻辑读取中更改的块的百分比。递归调用：递归调用占所有操作的百分比。如果有许多公共语言/SQL，递归调用的百分比会更高。每个事务回滚：每个事务的回滚速率。看看回滚率是否很高，因为回滚会消耗资源。如果回滚率太高，这可能表明您的数据库已经经历了太多的无效操作，并且太多的回滚也可能导致撤销块的竞争。此参数的计算公式如下：轮(用户回滚/(用户委员会用户回滚)，4) * 100%。每次排序的行数：一次排序的行数附注：甲骨文的硬分辨率和软分辨率当谈到软过程和硬过程时，我们必须谈谈甲骨文对sql的处理。当您向甲骨文发送一条sql语句时，甲骨文将在执行和获得结果之前分几个步骤处理该sql语句：1.语法检查请检查此sql的语法拼写。2.语义检查例如检查sql语句中的访问对象是否存在，以及用户是否拥有相应的权限。3.解析sql语句(prase)Sql通过内部算法进行分析，生成解析树和执行计划。4.执行sql并返回结果其中，软分析和硬分析发生在第三个过程中。Oracle使用内部哈希算法获取sql的哈希值，然后在库缓存中查找哈希值的存在。假设它存在，将此sql与缓存中的SQL进行比较；假设“相同”，将使用现有的解析树和执行计划，并省略优化器的相关工作。这也是软分析的过程。的确，如果以上两个假设都不成立，那么优化器将创建一个解析树并生成一个执行计划。这个过程被称为硬解析。创建解析树和生成执行计划对于sql执行来说是昂贵的操作，因此应该避免硬解析，并尽可能使用软解析。实例效率百分比(目标100%)缓冲区Nowait 3360100.00立即重做3360100.00缓冲命中336098.72内存排序336099.86图书馆点击336099.97软解析336099.92执行以解析336089.09闩锁命中336099.99解析中央处理器解析电子数据表33607.99%非解析CPU:99.95本节包括Oracle关键指标的内存命中率和其他数据库实例操作的效率。其中缓冲区命中率也称为缓存率，库命中率也称为库填充率。与负载概况部分一样，该部分没有所谓的“正确”值，只能根据应用的特性判断其是否合适。在使用直接读取来执行大型并行查询的DSS环境中，20%的缓冲区命中率是可以接受的，这对OLTP系统来说是完全不可接受的。根据甲骨文的经验，对于联机分析处理联机事务处理OLAP的主要应用是数据仓库系统。OLTP是在一般项目开发中使用的基本和常规事务。例如，数据库记录的添加、删除、修改和检查。理想的缓冲命中率应该在90%以上。Buffer Nowait表示不等待在内存中获得的数据的比例。获取缓冲区中缓冲区的等待比率。缓冲区当前值通常需要大于99%。否则，可能会发生争用，这可以在以后的等待事件中得到进一步确认。缓冲区命中指示进程在内存中查找数据块的速率。监控该值是否发生了显著变化比值本身更重要。对于正常的OLTP系统，如果该值小于80%，则应该为数据库分配更多的内存。数据缓冲区中数据块的命中率通常应该在95%以上。否则，如果小于95%，则需要调整重要参数，如果小于90%，则可以添加db_cache_size。高命中率并不一定意味着系统的性能是最佳的。例如，频繁访问大量非选择性索引，这将导致高命中率(大量数据库文件顺序读取)。然而，相对较低的命中率通常会影响系统的性能，需要进行调整。命中率的突然变化通常是一个坏消息。如果命中率突然增加，您可以检查顶部缓冲区获取SQL来查看导致大量逻辑读取的语句和索引。如果命中率突然降低，您可以检查顶级物理读取SQL来检查产生大量物理读取的语句，主要是那些不使用索引或其索引被删除的语句。Redo NoWait表示不等待获取缓冲