maclean-【性能调优】Oracle AWR报告指标全解析 学习笔记

原文链接：http://www.askmaclean.com/archives/performance-tuning-oracle-awr.html

AWR小技巧

手动执行一个快照：

Exec dbms_workload_repository.create_snapshot; (这个要背出来哦，用的时候去翻手册，丢脸哦 J!)

创建一个AWR基线

Exec DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id，end_snap_id ,baseline_name);

@?/rdbms/admin/awrddrpt AWR比对报告

@?/rdbms/admin/awrgrpt RAC 全局AWR

自动生成AWR HTML报告：
http://www.oracle-base.com/dba/10g/generate_multiple_awr_reports.sql
1、报告总结

Elapsed:               29.75 (mins)
DB Time:            7,633.76 (mins)

Elapsed 为该AWR性能报告的时间跨度(自然时间的跨度，例如前一个快照snapshot是4点生成的，后一个快照snapshot是6点生成的，则若使用@?/rdbms/admin/awrrpt 脚本中指定这2个快照的话，那么其elapsed = (6-4)=2 个小时)，一个AWR性能报告 至少需要2个AWR snapshot性能快照才能生成 ( 注意这2个快照时间 实例不能重启过，否则指定这2个快照生成AWR性能报告 会报错)，AWR性能报告中的 指标往往是 后一个快照和前一个快照的 指标的delta，这是因为 累计值并不能反映某段时间内的系统workload。

DB TIME= 所有前台session花费在database调用上的总和时间：

注意是前台进程foreground sessions

包括CPU时间、IO Time、和其他一系列非空闲等待时间，别忘了cpu on queue time

DB Time描绘了数据库总体负载，但要和elapsed time逝去时间结合其他来。

Average Active Session AAS= DB time/Elapsed Time

DB Time =60 min ， Elapsed Time =60 min AAS=60/60=1 负载一般

DB Time= 1min , Elapsed Time= 60 min AAS= 1/60 负载很轻

DB Time= 60000 min，Elapsed Time= 60 min AAS=1000 系统hang了吧？

DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue

如果仅有2个逻辑CPU，而2个session在60分钟都没等待事件，一直跑在CPU上，那么：

DB CPU= 2 * 60 mins ， DB Time = 2* 60 + 0 + 0 =120

AAS = 120/60=2 正好等于OS load 2。

如果有3个session都100%仅消耗CPU，那么总有一个要wait on queue

DB CPU = 2* 60 mins ，wait on CPU queue= 60 mins

AAS= (120+ 60)/60=3 主机load 亦为3，此时vmstat 看waiting for run time

1-1 内存参数大小

内存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)

1-2 Load Profile

指标

	指标含义
redo size	单位 bytes，redo size可以用来估量update/insert/delete的频率，大的redo size往往对lgwr写日志，和arch归档造成I/O压力， Per Transaction可以用来分辨是 大量小事务， 还是少量大事务。如上例每秒redo 约1MB ，每个事务800 字节，符合OLTP特征
Logical Read	单位 次数*块数， 相当于 “人*次”， 如上例 196,888 * db_block_size=1538MB/s ， 逻辑读耗CPU，主频和CPU核数都很重要，逻辑读高则DB CPU往往高，也往往可以看到latch: cache buffer chains等待。 大量OLTP系统(例如siebel)可以高达几十乃至上百Gbytes。
Block changes	单位 次数*块数 ， 描绘数据变化频率
Physical Read	单位次数*块数， 如上例 5076 * 8k = 39MB/s， 物理读消耗IO读，体现在IOPS和吞吐量等不同纬度上；但减少物理读可能意味着消耗更多CPU。好的存储 每秒物理读能力达到几GB，例如Exadata。 这个physical read包含了physical reads cache和physical reads direct
Physical writes	单位 次数*块数，主要是DBWR写datafile，也有direct path write。 dbwr长期写出慢会导致定期log file switch(checkpoint no complete) 检查点无法完成的前台等待。 这个physical write 包含了physical writes direct +physical writes from cache
User Calls	单位次数，用户调用数，more details from internal
Parses	解析次数，包括软解析+硬解析，软解析优化得不好，则夸张地说几乎等于每秒SQL执行次数。 即执行解析比1:1，而我们希望的是 解析一次 到处运行哦！
Hard Parses	万恶之源．　Cursor pin s on X， library cache: mutex X ， latch: row cache objects /shared pool……………..。 硬解析最好少于每秒20次
W/A MB processed	单位MB W/A workarea workarea中处理的数据数量 结合 In-memory Sort%， sorts (disk) PGA Aggr一起看
Logons	登陆次数， logon storm 登陆风暴，结合AUDIT审计数据一起看。短连接的附带效应是游标缓存无用
Executes	执行次数，反应执行频率
Rollback	回滚次数， 反应回滚频率， 但是这个指标不太精确，参考而已，别太当真
Transactions	每秒事务数，是数据库层的TPS，可以看做压力测试或比对性能时的一个指标，孤立看无意义
% Blocks changed per Read	每次逻辑读导致数据块变化的比率；如果’redo size’, ‘block changes’ ‘pct of blocks changed per read’三个指标都很高，则说明系统正执行大量insert/update/delete; pct of blocks changed per read = (block changes ) /( logical reads)
Recursive Call %	递归调用的比率;Recursive Call % = (recursive calls)/(user calls)
Rollback per transaction %	事务回滚比率。 Rollback per transaction %= (rollback)/(transactions)
Rows per Sort	平均每次排序涉及到的行数 ; Rows per Sort= ( sorts(rows) ) / ( sorts(disk) + sorts(memory))

1-3 Instance Efficiency Percentages (Target 100%)

Buffer Nowait %的计算公式是 sum(v$waitstat.wait_count) / (v$sysstat statistic session logical reads)

	Waits	Total Wait Time (s)	Avg Time (ms)
data block	24,543	2,267	92
undo header	743	2	3
undo block	1,116	0	0
1st level bmb	35	0	0

session logical reads

40,769,800

22,544.84

204.71

Buffer Nowait %:

99.94

Buffer Nowait= ( 40,769,800 – (24543+743+1116+35))/ ( 40,769,800) = 0.99935= 99.94%

buffer HIT%在 不同版本有多个计算公式：

在10g以后：

Buffer Hit Ratio= 1 – ((‘physical reads cache’) / (‘consistent gets from cache’ + ‘db block gets from cache’)

db block gets 、consistent gets 以及 session logical reads的关系如下：

db block gets＝db block gets direct＋　db block gets from cache

consistent gets　＝　consistent gets from cache＋　consistent gets direct

consistent gets from cache＝　consistent gets – examination + else

consistent gets – examination==>指的是不需要pin buffer直接可以执行consistent get的次数，常用于索引，只需要一次latch get

session logical reads = db block gets +consistent gets

其中physical reads 、physical reads cache、physical reads direct、physical reads direct (lob)几者的关系为：

physical reads = physical reads cache +　physical reads direct

这个公式其实说明了 物理读有2种 ：

物理读进入buffer cache中 ，是常见的模式 physical reads cache

物理读直接进入PGA 直接路径读， 即physical reads direct

physical reads direct = physical reads direct (lob) + physical reads direct temporary tablespace + physical reads direct(普通)

这个公式也说明了 直接路径读 分成三个部分：

physical reads direct (lob) 直接路径读LOB对象

physical reads direct temporary tablespace 直接路径读临时表空间

physical read direct(普通) 普通的直接路径读， 一般是11g开始的自动的大表direct path read和并行引起的direct path read

physical writes direct= physical writes direct (lob)+ physical writes direct temporary tablespace

DBWR checkpoint buffers written = DBWR thread checkpoint buffers written+ DBWR tablespace checkpoint buffers written+ DBWR PQ tablespace checkpoint buffers written+….

1-4 Shared Pool Statistics

% SQL with executions>1 复用的SQL占总的SQL语句的比率,数据来源 DBA_HIST_SQL_SUMMARY 的 SINGLE_USE_SQL和TOTAL_SQL：1 – SINGLE_USE_SQL / TOTAL_SQL

% Memory for SQL w/exec>1 执行2次以上的SQL所占内存占总的SQL内存的比率，数据来源DBA_HIST_SQL_SUMMARY 的SINGLE_USE_SQL_MEM和TOTAL_SQL_MEM：1 – SINGLE_USE_SQL_MEM / TOTAL_SQL_MEM

1-5 Top 5 Timed Events

Waits : 该等待事件发生的次数， 对于DB CPU此项不可用

Times : 该等待事件消耗的总计时间，单位为秒， 对于DB CPU 而言是前台进程所消耗CPU时间片的总和，但不包括Wait on CPU QUEUE

Avg Wait(ms) : 该等待事件平均等待的时间， 实际就是 Times/Waits，单位ms， 对于DB CPU此项不可用

% Total Call Time， 该等待事件占总的call time的比率

total call time = total CPU time + total wait time for non-idle events

% Total Call Time = time for each timed event / total call time

Wait Class: 等待类型：

Concurrency,System I/O,User I/O,Administrative,Other,Configuration,Scheduler,Cluster,Application,Idle,Network,Commit

几种常见的等待事件

=========================>

free buffer waits：是由于无法找到可用的buffer cache 空闲区域，需要等待DBWR 写入完成引起

buffer busy wait/ read by other session 一般以上2个等待事件可以归为一起处理，建议客户都进行监控

log file sync：一般此类等待时间是由于 LGWR 进程讲redo log buffer 写入redo log 中发生

2-1 Time Model Statistics

parse time elapsed、hard parse elapsed time 结合起来看解析是否是主要矛盾，若是则重点是软解析还是硬解析

sequence load elapsed time sequence序列争用是否是问题焦点

PL/SQL compilation elapsed time PL/SQL对象编译的耗时

注意PL/SQL execution elapsed time 纯耗费在PL/SQL解释器上的时间。不包括花在执行和解析其包含SQL上的时间

connection management call elapsed time 建立数据库session连接和断开的耗时

failed parse elapsed time 解析失败，例如由于ORA-4031

hard parse (sharing criteria) elapsed time 由于无法共享游标造成的硬解析

hard parse (bind mismatch) elapsed time 由于bind type or bind size 不一致造成的硬解析

2-2 Foreground Wait Class

Wait Class: 等待事件的类型，如上查询所示，被分作12个类型。 10.2.0.5有916个等待事件，其中Other类型占622个。

Waits: 该类型所属等待事件在快照时间内的等待次数

%Time Out 等待超时的比率， 未 超时次数/waits * 100 (%)

Total Wait Time: 该类型所属等待事件总的耗时，单位为秒

Avg Wait(ms) : 该类型所属等待事件的平均单次等待时间，单位为ms ，实际这个指标对commit 和 user i/o 以及system i/o类型有点意义，其他等待类型由于等待事件差异较大所以看平均值的意义较小

waits / txn: 该类型所属等待事件的等待次数和事务比

2-3 前台等待事件

Foreground Wait Events 前台等待事件，数据主要来源于DBA_HIST_SYSTEM_EVENT

Event 等待事件名字

Waits 该等待事件在快照时间内等待的次数

%Timeouts : 每一个等待事件有其超时的设置，例如buffer busy waits 一般为3秒， Write Complete Waits的 timeout为1秒，如果等待事件 单次等待达到timeout的时间，则会进入下一次该等待事件

Total Wait Time 该等待事件 总的消耗的时间 ，单位为秒

Avg wait(ms): 该等待事件的单次平均等待时间，单位为毫秒

Waits/Txn: 该等待事件的等待次数和事务比

2-4 后台等待事件

Event 等待事件名字

Waits 该等待事件在快照时间内等待的次数

%Timeouts : 每一个等待事件有其超时的设置，例如buffer busy waits 一般为3秒， Write Complete Waits的 timeout为1秒，如果等待事件 单次等待达到timeout的时间，则会进入下一次该等待事件

Total Wait Time 该等待事件 总的消耗的时间 ，单位为秒

Avg wait(ms): 该等待事件的单次平均等待时间，单位为毫秒

Waits/Txn: 该等待事件的等待次数和事务比

2-5 Operating System Statistics

统计项

	描述
NUM_CPU_SOCKETS	物理CPU的数目
NUM_CPU_CORES	CPU的核数
NUM_CPUS	逻辑CPU的数目
SYS_TIME	在内核态被消耗掉的CPU时间片，单位为百分之一秒
USER_TIME	在用户态被消耗掉的CPU时间片，单位为百分之一秒
BUSY_TIME	Busy_Time=SYS_TIME+USER_TIME 消耗的CPU时间片，单位为百分之一秒
AVG_BUSY_TIME	AVG_BUSY_TIME= BUSY_TIME/NUM_CPUS
IDLE_TIME	空闲的CPU时间片，单位为百分之一秒
所有CPU所能提供总的时间片	BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
OS_CPU_WAIT_TIME	进程等OS调度的时间，cpu queuing
VM_IN_BYTES	换入页的字节数
VM_OUT_BYTES	换出页的字节数，部分版本下并不准确，例如Bug 11712010 Abstract: VIRTUAL MEMORY PAGING ON 11.2.0.2 DATABASES，仅供参考
IOWAIT_TIME	所有CPU花费在等待I/O完成上的时间 单位为百分之一秒
RSRC_MGR_CPU_WAIT_TIME	是指当resource manager控制CPU调度时，需要控制对应进程暂时不使用CPU而进程到内部运行队列中，以保证该进程对应的consumer group(消费组)没有消耗比指定resource manager指令更多的CPU。RSRC_MGR_CPU_WAIT_TIME指等在内部运行队列上的时间，在等待时不消耗CPU

2-6 Service Statistcs

按照Service Name来分组时间模型和 物理、逻辑读取， 部分数据来源于 WRH$_SERVICE_NAME;

Service Name 对应的服务名 (v$services)， SYS$BACKGROUND代表后台进程， SYS$USERS一般是系统用户登录

DB TIME (s): 本服务名所消耗的DB TIME时间，单位为秒

DB CPU(s): 本服务名所消耗的DB CPU 时间，单位为秒

Physical Reads : 本服务名所消耗的物理读

Logical Reads : 本服务所消耗的逻辑读