原文链接：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 : 本服务所消耗的逻辑读