浅谈ORACLE AWR single instance 一
|
Oracle中的AWR，全称为Automatic Workload Repository，自动负载信息库。
AWR是DBA了解其运行状态的重要工具之一，根据AWR报告可以对oracle数据库性能整体了解并针对性优化，此文章主要是介绍AWR相关部分的内容。 DB Name DB Id Instance Inst Num Startup Time Release RAC ------------ ----------- ------------ -------- --------------- ----------- --- 1 16-Jan-17 09:27 11.2.0.4.0 NO Host Name Platform CPUs Cores Sockets Memory(GB) ---------------- -------------------------------- ---- ----- ------- ---------- Linux x86 64-bit 8 8 2 7.81 Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 10848 14-Mar-17 09:00:51 66 1.4 End Snap: 10849 14-Mar-17 10:00:55 66 1.5 Elapsed: 60.07 (mins) DB Time: 0.93 (mins) Sessions 采集性能信息时，oracle 实例链接的会话数，有助于判断DB的类 Cursors/Session 单个会话平均打开的游标数 Elapsed DB实际使用时间 DB Time 数据库操作花费的时间，包括CPU和Wait Event time，DB Time越高数据库，数据库负载越高。 通过DB Time/Elapsed 比值判断数据库的繁忙程度，比值越高，数据库越繁忙。 DB Time = CPU time + Wait time（不包括后台进程及空闲等待） 对应V$SESSION 中的elapsed_time Load Profile Per Second Per Transaction Per Exec Per Call ~~~~~~~~~~~~~~~ --------------- --------------- --------- --------- DB Time(s): 0.0 0.0 0.00 0.00 DB CPU(s): 0.0 0.0 0.00 0.00 Redo size (bytes): 1,343.6 3,388.8 Logical read (blocks): 394.1 993.9 Block changes: 5.4 13.6 Physical read (blocks): 0.4 1.1 Physical write (blocks): 0.6 1.4 Read IO requests: 0.4 1.1 Write IO requests: 0.4 1.1 Read IO (MB): 0.0 0.0 Write IO (MB): 0.0 0.0 User calls: 64.8 163.4 Parses (SQL): 21.0 52.9 Hard parses (SQL): 0.0 0.1 SQL Work Area (MB): 0.2 0.5 Logons: 0.1 0.2 Executes (SQL): 22.2 55.9 Rollbacks: 0.0 0.0 Transactions: 0.4 DB Time DB CPU DB Time 3.3s DB CPU 1.4s Wait Event 3.3-1.4=1.9s,DB CPU占DB Time的比重为1.4/3.3=42% 可以看出此DB系统的非CPU等待占比比较大 DB CPU占比42.55% db file sequential read/db file scattered read//libary cache:mutex X/latch:shared pool为CPU等待的TOP 4 wait event （DB Time > DB CPU + FG Wait event DB Time 会计算在CPU繁忙时的等待CPU的队列时间） 继续分析 redo size 日志的产生量 Logical reads 逻辑读，单位是块 良好的OLTP logical reads/ Executes 在50左右 Block Changes 每秒、事务改变的数据块 Physical reads 物理读 User Calls 每秒(每个事务)用户调用次数。User calls/Executes基本上代表了每个语句的请求次数，Executes越接近User calls越好 Pasre 解析次数，不包括快速软解析（MOS上说执行3次的SQL语句会把游标缓存到PGA，这个游标一直开着，当再有相同的SQL执行时，则跳过解析的所有过程直接去取执行计划） 软解析过多说明应用程序的效率不高 Hard Parse 硬解析的次数，此指标过高说明绑定变量没有做好 Sorts 排序次数 W/AMBprocessed 单位MBW/Aworkareaworkarea中处理的数据数量结合In-memorySort%，sorts(disk)PGAAggr一起看 Logon 登入数据库的次数 Executes 执行次数 Rollbacks 回滚次数 Transactions 事务数 Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 100.00 Redo NoWait %: 100.00 Buffer Hit %: 100.00 In-memory Sort %: 100.00 Library Hit %: 99.30 Soft Parse %: 99.79 Execute to Parse %: 5.27 Latch Hit %: 100.00 Parse CPU to Parse Elapsd %: 78.31 % Non-Parse CPU: 94.25 此模块记录oracle instance memory的使用信息，目标为100%，针对OLTP系统，此模块信息比较重要，对于OLAP系统，意义不大。 Buffer Nowait% 非等待方式获取数据块的百分比 这个值偏小，说明发生SQL访问数据块时数据块正在被别的会话读入内存，需要等待这个操作完成。发生这样的事情通常就是某些数据块变成了热块。 Buffer Nowait<95%说明，有可能是有热块(查找x$bh的 tch和v$latch_children的cache buffers chains)。 Redo Nowait 非等待获取redo数据 Buffer Hit% 数据缓存命中率 In-memory Sort% 数据排除操作在内存中的百分比 Library Hit% 共享池中SQL解析的命中率 （相关参数SHARED_POOL_SIZEBINGD VALUECURSOR_SHARING） Soft Parse % 软解析占解析的比率 value偏低表示DB中多数SQL没有被重用 <95%考虑绑定变量 Latch Hit% Latch的命中率 其值低是因为shared_pool_size过大或没有使用绑定变量导致硬解析过多。要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数。 Parse CPU to Parse Elapsd% 解析总时间中消耗CPU的时间百分比。即:100*(parse time cpu / parse time elapsed) 解析实际运行事件/(解析实际运行时间+解析中等待资源时间)，越高越好。 %Non-Parse CPU CPU非分析时间在整个CPU时间的百分比。 Shared Pool Statistics Begin End ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------ ------ Memory Usage %: 87.44 87.82 % SQL with executions>1: 98.06 97.25 % Memory for SQL w/exec>1: 92.56 92.46 Memory Usage % 共享池内存使用率。 应该稳定在70%-90%间，太小浪费内存，太大则内存不足。 % SQL with executions>1 执行次数大于1的SQL比率。 若太小可能是没有使用绑定变量。 % Memory for SQL w/exec>1 执行次数大于1的SQL消耗内存/所有SQL消耗的内存(即memory for sql with execution > 1)。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |