Oracle中的AWR,全称为Automatic Workload Repository,自动负载信息库。 AWR是DBA了解其运行状态的重要工具之一,根据AWR报告可以对oracle数据库性能整体了解并针对性优化,此文章主要是介绍AWR相关部分的内容。
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
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等待占比比较大
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/A MB processed 单位MB W/A workarea workarea中处理的数据数量 结合 In-memory Sort%, sorts (disk) PGA Aggr一起看 Logon 登入数据库的次数 Executes 执行次数 Rollbacks 回滚次数 Transactions 事务数
TOP 5 event
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的队列时间)
Instance Efficiency Percentage(Target 100%)
此模块记录oracle instance memory的使用信息,目标为100%,针对OLTP系统,此模块信息比较重要,对于OLAP系统,意义不大。
Buffer Nowait% 非等待方式获取数据块的百分比 这个值偏小,说明发生SQL访问数据块时数据块正在被别的会话读入内存,需要等待这个操作完成。发生这样的事情通常就是某些数据块变成了热块。
Redo Nowait 非等待获取redo数据 Buffer Hit% 数据缓存命中率 In-memory Sort% 数据排除操作在内存中的百分比 Library Hit% 共享池中SQL解析的命中率 (相关参数SHARED_POOL_SIZEBINGD VALUECURSOR_SHARING) Soft Parse % 软解析占解析的比率 value偏低表示DB中多数SQL没有被重用 <95%考虑绑定变量 Execute to Parse% 执行次数对解析次数的百分比 如果该值偏小,说明解析(硬解析和软解析)的比例过大,快速软解析比例小。根据实际情况,可以适当调整参数session_cursor_cache,以提高会话中sql执行的命中率。
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时间的百分比。 100*(parse time cpu / parse time elapsed)= Parse CPU to Parse Elapsd % 查询实际运行时间/(查询实际运行时间+sql解析时间),太低表示解析消耗时间过多。
shared pool statistics
Memory Usage %
共享池内存使用率。
% SQL with executions>1
执行次数大于1的SQL比率。 若太小可能是没有使用绑定变量。
% Memory for SQL w/exec>1
执行次数大于1的SQL消耗内存/所有SQL消耗的内存。 (编辑:李大同)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|