AWR学习记录

膜拜大神Maclean

生成AWR
@?/rdbms/admin/awrrpt.sql 本机
@?/rdbms/admin/awrrpti.sql RAC中其他实例号
创建AWR快照
exec dbms_workload_repository.create_snapshot;
创建AWR基线
exec dbms_workload_repository.create_baseline(start_snap_id,end_snap_id,baseline_name);

解析
1）报告总结

elapsed为该awr报告的时间跨度。
db time为所有前台session花费在database上的调用时间总和。
db time包括CPU时间、IO时间、其他一些非空闲等待时间。
db time不等于响应时间，高了未必响应慢，低了未必响应快。
db time描述了数据库在elapsed时间跨度内的数据库总负载。
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 CPUqueue
例：
如果仅有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= 60mins
AAS= (120+ 60)/60=3 主机load 亦为3，此时vmstat 看waiting for run time
真实世界中： DB Cpu = xx mins ， Non-Idle Wait= enq:TX +cursor pin S on X + latch : xxx + db file sequential read + …………

2）内存参数大小

内存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)
buffer cache和shared pool size的begin和end在ASMM、AMM和11gr2的MNMM下会变动。
如果share pool一直收缩，则在shrink（收缩）过程中一些row cache对象被lock可能会导致前台row cache lock等解析等待，share pool最好不要收缩。如果share pool一直grow（增长），则可能是share pool大小不够（可能大量硬解析），结合其他报告信息和sga breakdown一起诊断问题。

3）LoadProfile

注意这些load profile这些负载指标，本环节提供了两个维度，per second和per transaction。
per second：主要是把快照内的一些数值除以快照时间（秒），如A快照时间跨度1小时，开始时间硬解析数量为10，结束时间硬解析数量为370，则硬解析的per second为(370-10)/3600=0.1，每秒硬解析0.1次。
per second为审视数据库的主要维度。
per transaction：基于事务维度，与per second相比就是把除数从时间变成了事务数，这个维度很大的作用是用来识别应用特性的变化，若两个awr性能报告中该维度出现了大幅度变化，如redo size从1k变为了10k，则说明业务逻辑上发生了变化。

注意：这些指标并不仅仅用来孤立的了解oracle数据库的负载情况，实施调优工作，对于故障诊断如hang、crash等，完全可以通过对比问题时间段和常规时间段的性能报告，来找出问题原因。

3）instance Efficiency Percentages(Target 100%)

上述左右指标的目标均为100%，数值越大越好，在少数bug情况下可能会超过100%或者为负数。

①buffer nowait %：session申请一个buffer不等待的次数。即需要访问buffer时立即可以访问的次数，当数值过低时，可能出现的等待事件为buffer busy wait和read by other session。
②buffer hit %：高速缓存命中率，反应物理读和缓存命中之间的问题，但这个指标即使99%也不能说物理读等待少了。
不合理的db_cache_size或者ASMM、AMM都可能因为db_cache_size过小引起大量的db file sequential/
scattered read等待事件。
此外与buffer hit相关的指标还有table scans和（long tables）大表扫描统计项目、buffer pool statistics、buffer pool advisory等。
③redo nowait %：session在生成redo时不用等待的比例。redo相关的争用例如redo space request争用可能造成生成redo时需要等待。一般来说10g以后不用过于关注log buffer的大小，需要关注是否有是分频繁的log swtich。过小的redo logfile size如果配合较大的SGA和频繁的commit都可能造成该问题。考虑增大redo logfile的尺寸，1-4g每个，7-10组都是合适的，同时考虑优化redo log和datafile的I/O。
④In-memory sort %：这个指标因为不计算work area中的所有操作类型，所以使用越来越少，纯粹在内存中完成的排序比例。
⑤Library Hit %：library cache命中率，申请一个library cache object 例如sql cursor时，其已经在library cache中的比例。
维护这个指标的重点在于保持share pool有足够的free memory，且没有过多的内存碎片。过小的share pool可用空间会导致library cache object 因为aged out（年老）被换出share pool。
此外保证sql语句的绑定变量和游标可以共享也是很重要的因素。


⑥soft parse %：软解析比例。
该指标是AWR中一个重要的指标，反应了快照时间内软解析和总解析数的比例，弱该指标低，则说明硬解析过多，大量的硬解析会消耗更多的CPU时间并产生解析争用。理论上该指标最好是接近于100%，但并不是说100%的软解析是理想的状态。通过设置session_cached_cursors参数和反复重用游标我们可以让解析来的更轻量级，通俗说就是利用会话缓存游标来实现软软解析。
⑦execute to parse %：执行解析比。
目标为100%，只执行不解析。在oracle中往往解析是执行的前提，通过游标共享可以实现解析一次执行多次。
通俗的说soft parse%反应了软解析率，而软解析也是相对昂贵的操作，dba更希望解析一次执行n次，如果每次解析都是软解析，那么虽然soft parse%=100%，但是parse time仍可能是消耗DB TIME的罪魁祸首。
execute to parse反应了执行解析比，execute to parse 和soft parse%都很低，说明没有绑定变量。如果soft parse%接近100%而execute to parse不足90%，说明执行解析比低，需要通过静态SQL，动态绑定，session_cached_cursor，open cursors等技术减少软解析。
⑧latch hit %: willing to wait latch 闩申请不等待的比例。对于一个 并发设计良好的OLTP系统来说，latch和enqueue等并发控制不应当成为系统的主要瓶颈，同时对于这种并发争用而言堆积CPU和内存很难改善性能。
⑨perse CPU to perse elapsd :该指标为快照内解析CPU和总解析时间的比例。若该指标很低，说明在整个解析过程中实际在CPU上的运算时间很短，而主要的解析时间耗费在其他各种非空闲的等待事件上。
⑩%Non-parse CPU：非解析CPU比例，若大多数CPU都用在解析上，则可能好钢没用在刀刃上。

4）share pool statistics

该部分提供了一个大致的sql重用以及share pool内存使用的评估.
memory usage %：代表share pool空间的实时使用率，但是该数值虽然有使用率但是没有标明碎片程度。
% sql with executions >1：sql执行次数大于1的比例，如果该数值过低，考虑使用SQL抓取硬编码的非绑定变量的SQL语句。

select sql_id, FORCE_MATCHING_SIGNATURE, sql_text from v$SQL where FORCE_MATCHING_SIGNATURE in (select /*+ unnest */ FORCE_MATCHING_SIGNATURE from v$sql where FORCE_MATCHING_SIGNATURE > 0 and FORCE_MATCHING_SIGNATURE != EXACT_MATCHING_SIGNATURE group by FORCE_MATCHING_SIGNATURE having count(1) > 10)；

利用FORCE_MATCHING_SIGNATURE捕获非绑定变量SQL
% memory for sql w/exec >1：执行2次以上的SQL所占用内存占总SQL内存比例。
上面两个指标也可以用来大致了解share pool中内存碎片程度，因为single_use_sql（单次执行SQL）多的话，那么显然可能有碎片。
SQL复用率低一般来说就是非绑定变量，这种情况短期可以使用命令来绕过这个问题。
ALTER SYSTEM SETCURSOR_SHARING=FORCE;
这个参数是将多条类似的SQL语句用一个变量代替，可以短期使用，不建议长期使用，可能造成执行计划不准确，长期来说还是要修改代码为绑定变量。
如果memory usage %比例一直很高，则可以关注sga break down中的shared pool free memory大小，一般推荐至少让free memory有300-500MB来避免隐患。

5）top 5 timed events

基于wait interface的调优是主流，每个指标都很重要。
基于命中率的调优，好比统计局报告，张三有100W，李四有1W，平均财产50.5W。
基于等待事件调优，比如马路上100辆骑车的行驶记录，上车几分钟，红灯几分钟，堵塞几分钟等。
丰富的等待事件以足够的细节来描绘系统运行的瓶颈。
waits：等待事件发生的次数。
times：该等待事件在该快照中消耗的总计时间，单位秒。
avg wait(ms)：该等待事件平均等待事件，单位ms。
%total call time：该等待事件所等待时间占总等待事件的等待时间的比例。
wait class：等待类型。
Concurrency
System I/O
User I/O
Administrative
Other
Configuration
Scheduler
Cluster
Application
Idle
Network
Commit
几种常见等待事件：
db file scattered read：avg wait time 应当小于20ms，如果SQL执行全表扫描或者全索引扫描，会执行multi block I/O，此时等待物理I/O结束之后，会出现此等待事件，等待一个多数据块的I/O请求。一般会从SQL或者I/O方面调整。注意和instance activity stats中的index fast full scans(full)、table scans(longtables)集合一起看。

db file sequential read：该等待事件的avg wait time应当小于20ms。单块读等待是一种常见的物理I/O等待事件，这里的sequential是指将数据块读入到相连的内存中，而不是所读取的数据块是连续的。
该等待事件可能发生的情况

latch free：未获得latch，而进入latch sleep，见《全面解析9i以后Oracle Latch闩锁原理》。
enq:XX：队列锁等待，不同的队列锁有不同的情况。
你有多了解OracleEnqueue lock队列锁机制？
Oracle队列锁:Enqueue HW
Oracle队列锁enq:US,Undo Segment
enq: TX – rowlock/index contention、allocate ITL等待事件
enq: TT –contention等待事件
Oracle队列锁enq:TS,Temporary Segment (alsoTableSpace)
enq: JI –contention等待事件
enq: US –contention等待事件
enq: TM –contention等待事件
enq: RO fastobject reuse等待事件
enq: HW –contention等待事件

free buffer waits：无法找到可用的buffer cache，需要等dbwr写入完成引起。
可能造成的原因：
低效的SQL语句。
过小的buffer cache。
DBWR工作负荷过量。

buffer busy wait/read by other session：这两个等待事件可以一起处理，建议监控。
一般引起这两个等待事件的原因：
select/select----read by other session：由需要从数据块读取数据到buffer cache中引起。可能是大量的逻辑/物理读或者过小的buffer cache引起。
select/update----buffer busy wait/read by other session：由于更新某数据块后，需要在undo中重新构建过去时间的块，有可能伴生enq:cr-contention，由大量的物理/逻辑读造成。
update/update----buffer busy wait：由于更新同一个数据块（非同一行，同一行是enq:TX-contention）此类问题由热点块造成。
insert/insert----buffer busy wait：由于free list争用造成。可以将表空间更改为ASSM管理或者加大free list。

write complete waits：一般此类等待事件是由DBWR将脏数据写入数据文件，其他进程需要修改buffer cache造成，可能是I/O性能问题或者DBWR工作量过大.

control file parallel write：频繁更新控制文件造成大量此类等待事件，如日志切换，经常发生检查点，nologing引起频繁的数据文件修改，I/O性能缓慢。

log file sync：一般此类等待事件是由于LGWR进程将redo log buffer写入到redo log中发生，如果此类等待事件频繁发生，可能原因：
commit次数过多。
I/O性能问题。
重做日志是否不必要被创建。
redo log buffer是否过大。

6）time model statistics

该指标有几个特别有用：
parse time elapsed、hard parse elapsed time 结合起来看解析是否是主要矛盾，若是则重点是软解析还是硬解析。
sequence load elapsed time 序列争用是否是问题焦点。
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 不一致造成的硬解析。
该指标的模型中存在包含关系，所以时间加起来超过100%很正常。

包含关系

7）foreground wait class


wait class：等待事件类型，如上图所示，被分为12个类型。
waits：该类型所属等待事件在快照时间内的等待次数。
%time out：等待超时的比例。
total wait time：该类型所属等待事件的总耗时，单位秒。
avg wait(ms)：该类型所属等待事件的平均耗时，单位ms，实际该指标对commit、user i/o、system i/o类型有点意义，其他等到类型由于等待事件的差异较大所以看平均值意义较小。
waits/txn：该类型所属等待事件的等待次数和事务比。

other：遇到该类型等待事件，常见的原因是oracle bug或者网络、I/O存在问题。
concurrency：并行争用类型等待事件，典型的如latch:share pool，latch:library cache，row cache lock，library cache pin/lock。
cluster：为real application cluster rac环境中的等待事件，需要注意的是，如果启用了rac option，那么即使你的集群中只启动了一个实例，该实例也有可能遇到cluster类型的等待事件，如gc buffer busy。
system i/o：主要是后台进程维护数据库产生的I/O，如control file parallel write，log file parallel write，db file parallel write。
user i/o：主要是前台进程做的I/O操作，并不是说后台进程不会有这种等待事件。典型的如db file sequential/scattered read，direct path read。
configuration：由于配置引起的等待事件，例如日志切换的log file switch completion（日志文件大小、数目不够）sequence的enq:SQ-contention（sequnence使用nocache），oracle认为他们是由于配置不当引起的，但实际未必真的是这样的配置引起的。
application：应用造成的等待事件。例如enq:TM-contention和enq:TX-row lock contention，oracle认为这是由于应用设计不当造成，但实际上这些application class等待可能受到concurrency、cluster、system i/o、user i/o等多种类型等待的影响，例如本来commit只需要1ms，则某条数据只会被锁1ms，但由于commit变慢，从而释放行锁变慢，引发大量enq:TX-row lock contention等待。
commit：仅log file sync。
network：网络类型等待事件，例如SQLnet more data toclient、SQLnet more data to dblink
idle：空闲等待事件，最为常见的是rdbms ipc message（等待实例内部的ipc通信才工作，即别人通知有工作才开始干活，否则休息），SQLnet message from client（等到sqlnet传递信息，否则休息）。

8）foregroungd wait events

foregroungd wait events 前台等待事件。
event 等待事件名字。
waits 该等待事件在快照内等待次数。
%time outs 每一个等待事件有其超时的设置，例如buffer busy wait一般为3秒，write complete waits为1秒，如果等待事件单词等待达到time out的时间，则会进入下一次等待。
total wait time 该等待事件总耗时，单位秒。
avg wait(ms) 该等待事件的单词平均等待时间，单位ms。
waits/txn 该等待时间的等待次数和事务比。

9）background wait events

background wait events 后台等待事件。
event 等待事件名字。
waits 该等待事件在快照内等待次数。
%time outs 每一个等待事件有其超时的设置，例如buffer busy wait一般为3秒，write complete waits为1秒，如果等待事件单词等待达到time out的时间，则会进入下一次等待。
total wait time 该等待事件总耗时，单位秒。
avg wait(ms) 该等待事件的单词平均等待时间，单位ms。
waits/txn 该等待时间的等待次数和事务比。

10）operating system statistics

operating system statistics 操作系统统计信息。

11）service statistics

按照service statistics来分组时间模型和物理、逻辑读取。
service name 对应的服务名，background代表后台进程，users一般是系统用户登录。
db time(s) 本服务名所消耗的db time时间，单位秒。
db cpu(s) 本服务名所消耗的db cpu时间，单位秒。
physical reads 本服务名所造成的物理读。
logical reads 本服务名所造成的逻辑读。

12）service wait class stats

user i/o total wts 对应该服务名下用户i/o类型等待的总次数。
user i/o wt time 对应该服务名下用户i/o累计等待的总时间，单位1/100秒。
concurcy total wts 对应本服务名下concurrency类型等待的总次数。
concurcy wt time 对应本服务名下concurrencyt类型等待的总时间，单位1/100秒。
admin total wts 对应本服务名下admin类型等待的总次数。
admin wt time 对应本服务名下admin类型等待的总时间，单位1/100秒。
network total wts 对应本服务名下network类型等到的总次数。
network wt time 对应本服务名下network类型等待的总时间，单位1/100秒。

13）host cpu

locad average begin/end 代表每个cpu的大致运行队列大小，上例中快照运行到结束，平均cpu负载增加了，与第10相中的load相呼应。
%user+%system=>总的cpu使用率，上例中是31.8%。
elapsednum_cpuscou_utilization=elapsed2431.8%=cpu busy time

14）instance cpu

% of total cpu for instance 该实例所使用的cpu占总cpu的比例。
% of busy cpu for instance 该实例所使用的cpu占总的被使用的cpu的比例。
例如共4个逻辑cpu，其中3个被完全使用，3个中的1个被该实例完全使用，则%total cpu=25%，%busy cpu=33%。
当cpu高时一般看%busy cpu可以确定cpu到底是否是本实例消耗。

15）sql ordered by elapsed time

按照sql消耗的时间排列top sql。
elapsed time (s) 该sql累计运行所消耗时间。
executions 该sql在快照时间内总运行次数。注意，对于在快照时间内没有执行完成的sql不记为1次，所以如果看到executions=0，又是top sql，则说明该sql在快照时间内没执行完，则需要重点关注。
elapsed time per exec (s) 平均每次执行该sql耗费的时间。
对于oltp系统来说,select/insert/update/delete而言平均单次执行时间应当非常短，如0.1秒或者更短才能满足业务需求，如果这类轻微的oltp操作单次也要几秒的话，无法满足对外业务需求。如果操作变慢，则可能出现大量事务阻塞，系统负载升高，db time急剧上升的现象，对于oltp数据块而言，如果执行计划稳定，那么这些oltp操作的性能应该是固定的，但是一旦因为某个因素发生变化，例如存储变慢、内存换页的大量出现，则上述的这些操作很可能成倍数的变慢，这将让事务短期内不可用。
对于维护操作，例如加载或者清理数据、批量作业、报表而言，elapsed time per exec (s)高一些正常。
%total 该sql所消耗的时间占总db time的百分比。
%cpu 该sql所消耗的cpu时间占该sql消耗的时间的比例。该指标说明了该sql语句是否cpu敏感。
%i/o 该sql所消耗的i/o时间占该sql消耗的时间的比例。该指标说明了该sql语句是否i/o敏感。
sql id 通过计算sql文本获得的sql id，针对sql语句唯一，对于10g-11g而言，只要sql不变，那个在数据块之间，该sql的sql id也不变，12c中修改了sql id的算法。
captured sql account for 53.9% of total db time (s) 对于不绑定变量的应用来说，top sql有可能失准，所以参考这一项指标。
注意对于pl/sql，sql statistics不仅会体现该pl/sql的执行情况，还会包括该pl/sql包含的sql语句的情况。
如上例中一个top pl/sql执行了448s，而这448s中绝大多数是这个pl/sql下的一个sql执行500次消耗的。
则该top pl/sql和top sql都上榜，一个执行了一次耗时448s，一个执行了500次耗时448s，如此情况下elapsed time 加起来可能会超过100%的elapsed time，这很正常。
针对鹤立鸡群的sql，建议使用@?/rdbms/admin/awrsqrpt.sql查看。

16）sql ordered by cpu time

cpu time 该sql在快照时间内累计执行所消耗的cpu的时间，单位秒。
executions 该sql在快照时间内累计执行次数。
cpu per exec (s) 该sql平均单次执行所消耗的cpu时间。
%total 该sql累计消耗的cpu时间占快照时间内总的db cpu的比例。
%cpu 该sql所消耗的cpu时间占该sql消耗的总时间比例。
%i/o 该sql所消耗的i/o时间占该sql消耗的总时间的比例。

17）bffer gets sql ordered by gets

buffer gets 该sql在快照时间内累计运行所消耗的buffer gets，包含了consistent read 和current read。
executions 该sql在快照时间内累计执行的次数。
gets per exec 该sql平均单次的buffer gets，对于事务型操作而言，一般该单次buffer gets小于2000.
%total 该sql累计运行所消耗的buffer gets占总db buffer gets的比例。
注意，buffer gets逻辑读是消耗cpu time的重要源泉，但并不是说消耗cpu time的只有buffer gets。大多数情况下sql ordered by cpu time和sql ordered by buffer gets两个部分的top sql排序时一样的，此情况说明消耗最多buffer gets的就是消耗最多cpu time的sql，如果我们希望降低cpu使用率，那么只需要调优sql降低buffer gets即可。
但也并不是100%的情况都是如此，cpu time的消耗还包括函数运算、pl/sql控制、latch/mutex的spin等等，所以sql ordered by cpu time和sql ordered by buffer gets两个部分的top sql也可能完全不同，需要因地制宜来探究到底是什么问题导致high cpu。

18）physical reads sql ordered by reads

physical reads 该sql累计运行消耗的物理读。
executions 该sql快照时间内累计运行次数。
reads per exec 该sql单次运行所消耗的物理读，对于olpt类型的操作而言，单次一般不超过100.
%total 该sql累计消耗的物理读占快照时间内总物理读比例。

19）executions sql ordered by executions

executions 该sql快照时间内总执行次数。
rows processed 该sql快照时间内累计执行所处理的总行数。
rows per exec sql平均单次执行所处理的行数，这个指标在诊断一些数据问题造成的sql性能问题时很有用。
按照执行次数来排序的话，也是性能报告对比是一个重要的参考因素，因为如果top sql的执行次数明显增加，那么性能问题的出现也是情有可原。当然执行次数最多的，未必是对性能影响最大的top sql。

20）parse calls sql ordered by parse calls

parse calls 解析调用次数，包括软解析soft parse和硬解析hard parse。
executions 该sql快照时间内累计执行次数。
%total parses 该sql的解析调用次数在快照时间内总解析调用次数的占比。

21）sql ordered by sharable memory

sharable mem (b) sql对象所占用的共享内存使用量。
executions 该sql快照时间内累计执行次数。
%total 该sql对象快照时间内所占内存占总内存的比例。
sql ordered by sharable memory 一般该部分仅列出sharable memory(b)为1mb以上的sql对象。

22）sql ordered by version count

Version Count Oracle中的执行计划可以是多版本的，即对于同一个SQL语句有多个不同版本的执行计划，这些执行计划又称作子游标，而一个SQL语句的文本可以称作一个父游标。 一个父游标对应多个子游标，产生不同子游标的原因是SQL在被执行时无法共享之前已经生成的子游标， 原因是多种多样的，例如在本session中做了一个优化器参数的修改将optimizer_index_cost_adj 从100 修改到99，则本session的优化环境optimizerenv将不同于之前的子游标生成环境，这样就需要生成一个新的子游标。


可以看到上述 演示中修改optimizer_index_cost_adj=99 导致CBO 优化器的优化环境发生变化，表现为不同的OPTIMIZER_ENV_HASH_VALUE。
之后生成了2个子游标，但是这2个子游标的PLAN_HASH_VALUE同为3956160932，则说明了虽然是不同的子游标但实际子游标里包含了的执行计划是一样的。
所以请注意任何一个优化环境的变化以及相关衍生的BUG都可能导致子游标无法共享，虽然子游标无法共享但这些子游标扔可能包含完全一样的执行计划，这往往是一种浪费。
注意VERSION_COUNT未必等于select count(*) FROM V$SQL WHERESQL_ID=” 。
即 VERSION_COUNT 显示的子游标数目未必等于当前实例中还存有的子游标数目。
由于shared pool agedout算法和其他一些可能导致游标失效的原因存在，所以子游标被清理掉是很常见的事情。
VERSION_COUNT只是一个计数器，它告诉我们曾经生成了多少个childcursor，但不保证这些child 都还在shared pool里面。

此外可以通过v$SQL的child_number字段来分析该问题，如果child_number存在跳号则也说明了部分child被清理了。
当子游标过多(例如超过3000个时),进程需要去扫描长长的子游标列表child cursor list以找到一个合适的子游标child cursor，进而导致cursor sharing 性能问题 现大量的Cursor:Mutex S 和 library cache lock等待事件。
关于子游标的数量控制，可以参考《11gR2游标共享新特性带来的一些问题以及_cursor_features_enabled、_cursor_obsolete_threshold和106001event》。
Executions : 该SQL在快照时间内累计执行的次数。
Hash Value : 共享SQL 的哈希值。
Only Statements with Version Count greater than 20 aredisplayed 注意该环节仅列出version count > 20的语句。

23）cluster wait time sql ordered by cluster wait time

cluster wait time (s) 该sql在快照时间内累计执行过程中等待在集群等待上的时间，单位秒。可以理解为当一个sql在执行过程中遇到了gc buffer busy、gc cr multi block request之类的cluster等待，这些等待消耗的时间全部算在内。
executions 该sql快照时间内累计执行次数。
%total 该sql所消耗的cluster wait time占总cluster wait time的比例。
%clu 该sql所消耗的cluster wait time占该sql的总耗时的比例。
%cpu 该sql所消耗的cpu时间占该sql的总耗时的比例。
%i/o 该sql所消耗的i/o时间占该sql的总耗时的比例。

34）instance activity stats

这里每一个指标都代表一种数据库行为的活跃度，例如redi size指redo生成量，sorts(disk)指磁盘排序的次数，table scans(direct read)指直接路径扫描表的次数。
total 该行为在快照时间内的总次数。
per second 该行为快照时间内每秒的次数。
per trans 该行为快照时间内每事务的次数。
该指标在诊断问题是十分有用。
例如：
当 Top Event 中存在direct path read为Top 等待事件，则需要分清楚是对普通堆表的directread还是由于大量LOB读造成的direct path read，这个问题可以借助 table scans (direct read)、table scans (long tables)、physical reads direct 、physical reads direct(lob) 、physical reads direct temporary几个指标来分析， 假设 physical reads direct>> 远大于 physical reads direct (lob)+physical reads direct temporary ， 且有较大的table scans (direct read)、table scans (long tables) (注意这2个指标代表的是 扫描表的次数 不同于上面的physical reads 的单位为 块数*次数)， 则说明了是大表扫描引起的direct path read。

当 Top Event中存在enq Tx:index contention等待事件， 则需要分析root node splits 、branch node splits 、leaf node 90-10 splits 、leaf node splits、failed probes on index block rec 几个指标具体可以见文档《Oracle索引块分裂split信息汇总》。

当系统出现IO类型的等待事件为top Five 例如 db file sequential/scattered read，我们需要通过AWR来获得系统IO吞吐量和IOPS:
physical read bytes 主要是应用造成的物理读取(Total size in bytes of all disk reads by application activity (and not other instance activity)only.) 而physical read total bytes则包括了 rman备份恢复和后台维护任务所涉及的物理读字节数，所以我们在研究IO负载时一般参考 physical read total bytes。
以下4对指标均存在上述的关系

总的物理吞吐量/秒=physical read total bytes+physical write total bytes
总的物理IOPS= physical read total IO requests+ physical write total IOrequests
IO的主要指标 吞吐量、IOPS和延迟 均可以从AWR中获得了， IO延迟的信息可以从 User I/O的Wait Class Avg Wait time获得，也可以参考11g出现的IO stat by Function summary。

Instance Activity Stats有大量的指标，但是对于这些指标的介绍没有那一份文档有完整详尽的描述，即便在Oracle原厂内部要没有(或者是Maclean没找到)，实际是开发人员要引入某一个Activity Stats是比较容易的，并不像申请引入一个新后台进程那样麻烦，Oracle对于新版本中新后台进程的引入有严格的要求，但Activity Stats却很容易，往往一个one-off patch中就可以引入了，实际上Activity Stats在源代码层仅仅是一些计数器。

instance activity stats - absolute values 是显示快照起点和终点的一些指标的绝对值。
logons current 当前时间点的登录数。
opened cursors current 当前打开的游标数。
session cursor cache count 当前存在的session缓存游标数。

log switches (derived) 日志切换次数
《理想的在线重做日志切换时间是多长？》

35）tablespace io stats 基于表空间分组的io信息

reads 该表空间上发生的物理读次数。
av reads/s 该表空间上平均每秒的物理读次数。
av rd (ms) 该表空间上每次读的平均读取延迟。
av blks/rd 该表空间上平均每次读取的块数目。因为一次物理读可以读取多个块。
如果av blks/rd >1则可能系统有较多db file scattered read 可能是诊断full table scan或fast full index scan，需要关注table scans (long tables) 和index fast full scans (full) 两个指标。
writes 该表空间上发生的物理写次数。对于那些writes总是等于0的表空间可以了解下是否数据为只读，如果是可以通过read only tablespace 来解决rac中的一些性能问题。
av writes/s 该表空间上平均每秒的物理写次数。
buffer waits 该表空间上发生buffer busy wait 和read by other session的次数。
av buf wt (ms) 该表空间上发生buffer wait 的平均等待事件，单位ms。

36）file i/o

tablespace 表空间名。
filename 数据文件路径。
reads 该数据文件上累计发生的物理读次数。
av reads/s 该数据文件上平均每秒发生的物理读次数。
av rd (ms) 该数据文件上平均每秒发生的物理读延迟，单位ms。
av blks/rd 该数据文件上平均每次读取涉及到的块数。oltp环境该值接近1。
writes 该数据文件上累计发生的物理写次数。
av writes/s 该数据文件上平均每秒发生的物理写次数。
buffer waits 该数据文件上发生buffer busy wait和read by other session的次数。
av buf wt (ms) 该数据文件上发生buffer wait的平均等待事件，单位ms。
若某个表空间上有较高的io负载，则有必要分析一下是否其所属的数据文件上的io较为均匀还是存在倾斜，是否需要结合存储特征来均衡分布到不同磁盘上的数据文件上，以优化io。

37）buffer pool statistics 缓冲池统计

P pool池的名字，D：默认缓冲池 defaule buffer pool；K：keep pool；R：recycle pool；2k,4k,8k,16k,32k代表各种非标准块大小的缓冲池。
number of buffers 实际的缓冲块数目。
pool hit% 该缓冲池的命中率。
buffer gets 该缓冲池中块的访问次数。包括consistent gets和db block gets。
physical reads 该缓冲池buffer cache引起了多少物理读。其实是physical reads cache。
physical writes 该缓冲池buffer cache引起了多少物理写。其实是physical writes from cache。
free buffer wait 等待空闲缓存的次数。可以看做该buffer pool发生free buffer wait的次数。
write comp wait 等待dbwn写入脏数据的次数。可以看做该buffer pool发生write complete waits的次数。
buffer busy waits 该缓冲池发生buffer busy wait的次数。

38）checkpoint activity 检查点与instance recovery stats 实例恢复

mttr writes 为了满足fast_start_mttr_target指定的mttr值而做出的物理写 write——mttr。
log size writes 由于最小的redo log而做出的物理写writes_logfile_size。
log ckpt writes 由于 LOG_CHECKPOINT_INTERVAL 和 LOG_CHECKPOINT_TIMEOUT 驱动的增量检查点而做出的物理写 WRITES_LOG_CHECKPOINT_SETTINGS
other settings writes 由于其他设置(例如FAST_START_IO_TARGET）而引起的物理写， WRITES_OTHER_SETTINGS
autotune ckpt writes 由于自动调优检查点而引起的物理写， WRITES_AUTOTUNE
thread ckpt writes 由于thread checkpoint而引起的物理写，WRITES_FULL_THREAD_CKPT
B 开始点
E 结尾点
targt mttr (s) 目标MTTR (mean time to recover)意为有效恢复时间，单位为秒。 TARGET_MTTR 的计算基于 给定的参数FAST_START_MTTR_TARGET，而TARGET_MTTR作为内部使用。 实际在使用中 Target MTTR未必能和FAST_START_MTTR_TARGET一样。 如果FAST_START_MTTR_TARGET过小，那么TARGET_MTTR 将是系统条件所允许的最小估算值；如果FAST_START_MTTR_TARGET过大，则TARGET_MTTR以保守算法计算以获得完成恢复的最长估算时间。
estd mttr (s) 当前基于 脏buffer和重做日志块的数量，而评估出的有效恢复时间 。 它的估算告诉用户 以当下系统的负载若发生实例crash，则需要多久时间来做crash recovery的前滚操作，之后才能打开数据库。
recovery estd ios 实际是当前buffer cache中的脏块数量，一旦实例崩溃 这些脏块要被前滚。
actual redoblks 当前实际需要恢复的redo重做块数量.
target redoblks 是 Log Sz RedoBlks 、Log Ckpt Timeout RedoBlks、 Log Ckpt Interval RedoBlks 三者的最小值。
log sz redoblks 代表 必须在log file switch日志切换之前完成的 checkpoint 中涉及到的redo block，也叫max log lag。
log ckpt timeout redoblks 为了满足LOG_CHECKPOINT_TIMEOUT 所需要处理的redo block数，lag for checkpoint timeout。
log ckpt interval redoblks 为了满足LOG_CHECKPOINT_INTERVAL 所需要处理的redo block数， lag for checkpoint interval。
opt log sz (M) 基于FAST_START_MTTR_TARGET 而估算出来的redo logfile 的大小，单位为MB 。 Oracle官方推荐创建的重做日志大小至少大于这个估算值。
estd rac avail time 指评估的 RAC中节点失败后 集群从冻结到部分可用的时间， 这个指标仅在RAC中可用，单位为秒。

39）buffer pool advisory 缓冲池建议

缓冲池的颗粒大小，可以参考SELECT * FROM V$SGAINFO where name like(‘Granule%’);
P 缓冲池的名字 ，可能包括 有 D default buffer pool , K Keep Pool , R recycle Pool。
size for est (M) 指以该尺寸的buffer pool作为评估的对象，一般是 目前current size的 10% ~ 200%，以便了解 buffer pool 增大到减小对物理读的影响。
size factor 尺寸因子，只对应buffer pool 大小对当前设置的比例因子，例如current_size是 100M ，则如果评估值是110M那么size Factor 就是 1.1。
buffers (thousands) 指这个buffer pool 尺寸下的buffer 数量， 要乘以1000才是实际值。
est phys read factor 评估的物理读因子，例如当前尺寸的buffer pool会引起100个物理读，则别的尺寸的buffer pool如果引起120个物理读 ，那么对应尺寸的Est Phys Read Factor就是1.2。
estimated phys reads (thousands) 评估的物理读数目，要乘以1000才是实际值，显然不同尺寸的buffer pool对应不同的评估的物理读数目。
est phys read time 评估的物理读时间。
est %dbtime for rds 评估的物理读占db time得比例。
我们关注buffer pool advisory一般有两个目的：
1.在物理读较多的情况下，希望通过增加buffer pool 大小来缓解物理读等待，这是我们关注Size Factor > 1的buffer pool尺寸是否能有效减少Est Phys Read Factor，如果Est Phys Read Factor随着Size Factor增大而显著减少，那么说明增大buffer cache是可以有效减少物理读的。
2.在内存紧张的情况下 ，希望从buffer pool中匀出部分内存来移作他用，但是又不希望buffer cache变小导致物理读增多性能下降，则此时观察Est Phys Read Factor是否随着Size Factor减小而显著增大，如果不是则说明减少部分buffer cache不会导致物理读大幅增加，也就可以安心减少buffer cache。
注意 Size Factor 和 Est Phys Read Factor之间不是简单的 线性关系，所以需要人为介入评估得失。