AWR分析
AWR介绍
AWR (Automatic Workload Repository)
一堆历史性能数据，放在SYSAUX表空间上， AWR和SYSAUX都是10g
现的，是Oracle调优的关键特性； 大约1999年左右开始开发，已经有21年
历史
默认快照间隔1小时， 10g保存7天、 11g保存8天; 可以通过
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS修改
AWR程序核心是dbms_workload_repository包
@?/rdbms/admin/awrrpt 本实例
@?/rdbms/admin/awrrpti RAC中选择实例号
@?/rdbms/admin/awrddrpt AWR比对报告
@?/rdbms/admin/awrgrpt RAC 全局AWR
exec dbms_workload_repository.create_snapshot; //手工生成快照
(这个要背出来哦，用的时候去翻手册，丢脸哦 ☺!)
AWR维护：
主要是MMON(Manageability Monitor Process)和它的小工进程(m00x)
MMON的功能包括:
1. 启动slave进程m00x去做AWR快照
2. 当某个度量阀值被超过时发出alert告警
3. 为最近改变过的SQL对象捕获指标信息
二、报文头-DB Time
其他备注：
Startup Time：实例启动时间
CPUs：逻辑CPU数
Cores：总CPU核数
Sockets：物理cpu个数
DB TIME= 所有前台session花费在database调用上的总和时间
• 注意是前台进程foreground sessions
• 包括 CPU时间、 IO Time、和其他一系列非空闲等待时间，别忘了cpu on queue time
DB TIME 不等于 响应时间， DB TIME高了未必响应慢， DB 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
AAS=OS LOAD，如果os load=总cpu数，按cpu就是全部100%忙
如上图所示，某个点t的活动回话是2
DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue
(cpu+cpu队列+非空闲等待—背下来)
举例：
如果仅有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，os load=总逻辑cpu
如果有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
以上在真实环境是不存在的。
真实世界中如下：
DB Cpu = xx mins ， Non-Idle Wait= enq:TX + cursor pin
S on X + latch : xxx + db file sequential read + ……….. 阿猫阿狗
实战dbtime
案例一
（Time Model Statistics）
从上图看到 db cpu只占用db time 很小的比例，所以db cpu不是瓶颈
备注： 下面的db time（s）=上面的db time（单位分钟）* 60
2>查询最新7天的db_time
WITH sysstat AS
(select sn.begin_interval_time begin_interval_time,
sn.end_interval_time end_interval_time,
ss.stat_name stat_name,
ss.value e_value,
lag(ss.value, 1) over(order by ss.snap_id) b_value
from dba_hist_sysstat ss, dba_hist_snapshot sn
where trunc(sn.begin_interval_time) >= sysdate - 7
and ss.snap_id = sn.snap_id
and ss.dbid = sn.dbid
and ss.instance_number = sn.instance_number
and ss.dbid = (select dbid from v$database)
and ss.instance_number = (select instance_number from v$instance)
and ss.stat_name = 'DB time')
select to_char(BEGIN_INTERVAL_TIME, 'mm-dd hh24:mi') || to_char(END_INTERVAL_TIME,
'
hh24:mi') date_time,
stat_name,
round((e_value - nvl(b_value, 0)) /
(extract(day from(end_interval_time - begin_interval_time)) * 24 * 60 * 60 +
extract(hour from(end_interval_time - begin_interval_time)) * 60 * 60 +
extract(minute from(end_interval_time - begin_interval_time)) * 60 +
extract(second from(end_interval_time - begin_interval_time))),
0) per_sec
from sysstat
where (e_value - nvl(b_value, 0)) > 0
and nvl(b_value, 0) > 0;
Load Profile 和Cache Sizes
1、Load Profile
Redo size 单位 bytes， redo size可以用来估量update/insert/delete的频率，大的redo size往往对lgwr写日志，和arch归档造成I/O压力， PerTransaction可以用来分辨是 大量小事务， 还是少量大事务。如上例每秒redo 约0.2MB ，每个事务1k，符合OLTP特征
Logical Read单位 次数*块数， 相当于 “人*次”， 如上例 1579406 *
db_block_size=12GB/s， 逻辑读耗CPU，主频和CPU核数都很重要，逻辑读高则DB CPU往往高，也往往可以看到latch: cache buffer chains等待。
大量OLTP系统(例如siebel)可以高达几十乃至上百Gbytes。
Block changes 单位 次数*块数 ， 描绘数据变化频率
Physical Read 单位次数*块数， 如上例 5557 * 8k = 43MB/s， 物理读消耗
IO读，体现在IOPS和吞吐量等不同纬度上；但减少物理读可能意味着消
耗更多CPU。好的存储 每秒物理读能力达到几GB，例如Exadata
Physical writes单位 次数*块数，主要是DBWR写datafile，也有direct
path write。 dbwr长期写出慢会导致定期log file switch(checkpoint no complete) 检查点无法完成的前台等待。
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次
hard parses 高实战案例
从上图得出结论：
硬解析数和 hard parse elapsed time对应， 看一眼TimeModel Statistics，即可知该系统是否 是 解析敏感的
这里的 log file sync高是大量commit导致每小时1.5G的redo 导致的，所以不是主因。（这个分析看最下面的 log file sync等待分析）
下面分析 row cache objects等待时间。看 Latch Miss Sources
第三列是函数名，根据以上提示的函数名知道字典sleeps多，进一步查看字典cache信息：
最终解决办法建议：
- 让应用绑定绑定变量减少物理解析，应用没办法更改设置 cursor_sharing=force
- 介绍直方图争用-删除该列的直方图信息
2、cache sizes
内存管理方式： MSMM、 ASMM(sga_target)、 AMM(memory_target)
小内存有小内存的问题， 大内存有大内存的麻烦！
ORA-04031: 无法分配 4064 字节的共享内存
Buffer cache和shared pool size的 begin/end值在ASMM、 AMM和11gR2 MSMM下可是会动的哦！
如果这里 shared pool一直收缩，则在shrink过程中一些row cache 对象被lock住可能导致前台row cache lock等解析等待，最后别让shared pool shrink。
如果这里shared pool一直在grow，那说明shared pool原有大小不足以满足需求(可能是大量硬解析)，结合下文的解析信息和SGA breakdown来一起诊断问题。
四、Instance Efficiency Percentages
基于命中率的调优方法论已经过时，但仍具有参考价值：
全部是越高越好！
Buffer nowait%: session申请一个buffer(兼容模式)不等待的次数比例。
Buffer HIT%: 经典的经典，高速缓存命中率，反应物理读和缓存命中间的纠结，
但这个指标即便99% 也不能说明物理读等待少了
Redo nowait%: session在生成redo entry时不用等待的比例， redo相关的资源争用，例如redo space request争用可能造成生成redo时需求等待。此项数据来源于v$sysstat中的redo log space requests/redo entries
In-memory Sort%:这个指标因为它不计算workarea中所有的操作类型，所以现在越来越鸡肋了。 纯粹在内存中完成的排序比例。
Library Hit%: library cache命中率，申请一个library cache object例如一个SQL cursor时，其已经在library cache中的比例。
Soft Parse: 软解析比例，无需多说的经典指标，数据来源v$sysstat statistics的
parse count(total)和parse count(hard)。 合理值>95%
Execute to Parse% 指标反映了执行解析比 其公式为 1-(parse/execute) , 目标为100% 及接近于只 执行而不解析。 数据来源v$sysstat statistics parse count (total) 和execute count
Latch Hit%: willing-to-wait latch闩申请不要等待的比例。
Parse CPU To Parse Elapsd:该指标反映了 快照内解析CPU时间和总的解析时间的比值(Parse CPUTime/ Parse Elapsed Time)； 若该指标水平很低，那么说明在整个解析过程中 实际在CPU上运算的时间是很短的，而主要的解析时间都耗费在各种其他非空闲的等待事件上了(如latch:shared pool,rowcache lock之类等)
%Non-Parse CPU 非解析cpu比例，公式为 (DB CPU – Parse CPU)/DB CPU， 若大多数CPU都用在解析上了，则可能好钢没用在刃上了。
shared Pool Statistics
该环节提供一个大致的SQL重用及shared pool内存使用的评估。 应用是否共享SQL? 有多少内存是给只运行一次的SQL占掉的，对比共享SQL呢？
如果该环节中% SQL with executions>1的 比例 小于%90 ， 考虑用下面链接的SQL去抓 硬编码的非绑定变量SQL语句。
六、Top 5/10 Foreground Event
DB CPU/CPU time是Top 1 是好事情吗？ 未必！
注意DB CPU不包含 wait on cpu queue！
db cpu
db cpu time 不包含cpu队列等待
2、db file sequential read / scattered read
1> db file sequential read
Avg wait time应当小于20ms
”db file sequential read”单块读等待是一种最为常见的物理IO等待事件，这
里的sequential指的是将数据块读入到相连的内存空间中(contiguous
memory space)，而不是指所读取的数据块是连续的。
单块读不会被缓存，因为它是对表后面后者前面的额外块的读取，它读取的频率非常低。
该wait event可能在
以下情景中发生:
1>最为常见的是执行计划中包含了INDEX FULL SCAN/UNIQUE SCAN,此时出现”db file sequential read”等待是预料之中的，一般不需要我们去特别关注
2>当执行计划包含了INDEX RANGE SCAN-(“TABLE ACCESS BY INDEX ROWID”/”DELETE”/”UPDATE”)， 服务进程将按照”访问索引->找到rowid->访问rowid指定的表数据块并执行必要的操作”顺序访问index和table，每次物理 读取都会进入”db file sequential read”等待，且每次读取的都是一个数据块；这种情况下clustering_factor将发挥其作用，需要我们特别去关注，本例中提及的解决方法对 这种情景也有效
3>Extent boundary,假设一个Extent区间中有33个数据块，而一次”db file scattered read”多块读所读取的块数为8，那么在读取这个区间时经过4次多块读取后，还剩下一个数据块，但是请记住多块读scattered read是不能跨越一个区间的(span an extent)，此时就会单块读取并出现”db file sequential read”。这是一种正常现象，一般不需要额外关注
4>假设某个区间内有8个数据块，它们可以是块a,b,c,d,e,f,g,h，恰好当前系统中除了d块外的其他数据块都已经被缓存在buffer cache中了，而这时候恰好要访问这个区间中的数据，那么此时就会单块读取d这个数据块，并出现”db file sequential read”等待。注意这种情况不仅于表，也可能发生在索引上。这是一种正常现象，一般不需要额外关注
5>chained/migrated rows即链式或迁移行，这里我们不介绍链式行的形成原因，chained/migrated rows会造成服务进程在fetch一行记录时需要额外地单块读取，从而出现”db file sequential read”。这种现象需要我们特别去关注，因为大量的链式/迁移行将导致如FULL SCAN等操作极度恶化(以往的经验是一张本来全表扫描只需要30分钟的表，在出现大量链式行后，全表扫描需要数个小时)，同时也会对其他操作造成不那么 明显的性能影响。可以通过监控v$sysstat视图中的”table fetch continued row”操作统计来了解系统中链式/迁移行访问的情况，还可以通过DBA_TBALES视图中的CHAIN_CNT来了解表上的链式/迁移行情况，当然这 要求定期收集表上的统计信息；如果没有定期收集的习惯，那么可以配合@?/rdbms/admin/utlchain脚本和analyze table list chained rows 命令来获取必要的链式行信息
这个数据可以看是否存在链式或迁移行 应该每秒小于200次。
6>创建Index entry，显然当对表上执行INSERT操作插入数据时，虽然在执行计划中你看不到过多的细节，但实际上我们需要利用索引来快速验证表上的某些约束是否 合理，还需要在索引的叶子块中插入相关的记录，此时也可能出现”db file sequential read”等待事件，当然这还和具体的插入的方式有关系。这是一种正常现象，一般不需要额外关注
7>针对表上的UPDATE/DELETE，不同于之前提到的”INDEX RANGE SCAN-UPDATE/DELETE”，如果我们使用rowid去更新或删除数据时，服务进程会先访问rowid指向的表块(注意是先访问table block)上的行数据，之后会根据该行上的具体数据去访问索引叶子块(注意Oracle并不知道这些leaf block在哪里，所以这里同样要如range-scan/unique-scan那样去访问index branch block)，这些访问都将会是单块读取，并会出现’db file sequential read’，完成必要的读取后才会执行更新或删除的实际EXEC操作
8>BUG!BUG!已知在9i RAC及10g中使用ASM的情况下，存在引发在适用情况下不使用”scattered read”多块读而去使用”sequential read”的BUG。如果你的问题和上述情景都不匹配，但又有大量的”db file sequential read”等待事件，那么你有可能遇到bug了
db file scattered read
这里的scattered指的是读取的数据块在内存中的存放方式，他们被读取到内存中后，是以分散的方式存在在内存中，而不是连续的。
Avg wait time应当小于20ms
常见原因 Fast Full scan Index ， FULL SCAN large table
通过以上两个指标查看目前系统中是否有Fast Full scan Index 读和 FULL SCAN large table读
sequential和scattered read 解题思路
出现这两个等待都可以去看SQL ordered by Reads 和 Segments by Physical Reads
log file sync 等待事件
最糟糕的就是log file sync不在top 5列表里从而引起的连锁等待事件：
Log file sync 🡺 enq: TX ， gc buffer busy， buffer busy wait , enq:TX index contention
这就是等待事件的混沌理论：性能不是线性的，而是多纬度的
案例1-log file parallel write 慢导致其他等待
有个视频网址，有一天突然说慢了（啥变更也没），等待事件如下。无经验的dba就会说是tx 锁导致的，让去优化语句。这里都是典型的 log file sync导致的蝴蝶效应：
log file parallel write慢=> log file sync慢=>commit慢， commit慢=>释放
行锁慢。
在rac环境中rac flush redo也受到写redo慢的影响，从而出现gc buffer busy release/acquire，前后相互作用🡺 enq:TX 大幅出现
从上图看很容易误以为是 行锁导致的
如果 top 5里面有log file sync，先看 log file parallel write,如下：
17ms，这个很高了，一般都是1ms左右
从上图可以看到 global cache 达到了 30以上，（正常值是不超过5ms）
flush 是Oracle为了保证Instance Recovery实例恢复机制，而要求每一个current block在本地节点local instance被修改后(modify/update) 必须要将该current block相关的redo 写入到logfile 后（要求LGWR必须完成写入后才能返回)，才能由LMS进程传输给其他节点使用。RAC 的Redo flush慢造成gc buffer busy release/acquire等待
从以上图可以看到每秒94个commit
行锁都是在block上的
enq:TX row lock出现在哪里？哪些语句受到GC buffer busy影响？
最主要是update和insert 受影响，前台处理业务速度放慢。
Global Buffer Busy 🡺 gc buffer busy acquire/release 受影响的segment
这里有迷惑性，实际是commit造成的
2、案例2-redo 每分钟1.5G造成log file sync高
从上图可以看到 log file sync等待最高，完了去看 load profile的 redo size 量
从上图可以看到 redo size 25M/S,一分钟是25*60=1.5G 相当吓人
完了去看 user commit:
每秒 1760次，典型的oltp操作。这个是可以导致 log file sync的，所以这个log file sync是合理的。
gc buffer busy等待事件
跨实例访问热快造成的。
本实例第一个申请该current block时进入gc current request，本实例后续其他进程若又发起对该current block的申请则均进入’gc buffer busy acquire’
等待。
11g后gc buffer busy分成 ’gc buffer busy acquire’ 和 ’gc buffer busy
release了
11g开始gc buffer busy分为gc buffer busy acquire和gc buffer busy release:
gc buffer busy acquire是当session#1尝试请求访问远程实例(remote instance) buffer，但是在session#1之前已经有相同实例上另外一个session#2请求访问了相同的buffer，并且没有完成，那么session#1等待gc buffer busy acquire。（等待本实例的其他回话释放访问的远程buffer cache）
gc buffer busy release是在session#1之前已经有远程实例的session#2请求访问了相同的buffer，并且没有完成，那么session#1等待gc buffer busy release。
（等待其他实例的回话释放访问的buffer cache）
gc buffer busy造成的最根本原因是跨实例访问buffer cache。所以减少cache访问可以降低该等待，最终减少逻辑读
1>案例一：block receive 高造成gc 等待
Avg global cr/current block receive time高🡺 本实例出现大量cluster等待
Avg global cache cr/current pin/send/flush time高🡺 本实例server global cache也不给力啊，其他节点的性能大致也和此处一副德性
2>案例二： gc影响 enq:TX-ROW LOCK
大量Cluster Wait，平均每次等241ms，而一个事务平均等9.2次，则一个事务平均等Cluster 2秒（0.241s*9.2），换句话说如果不是RAC，每个事务提速2s!!
Cluster Wait并不孤立，会影响Application类型的enq: TX - row lock contention等待事件出现的频率和单次等待耗时
如上例中 平均 每个事务要等一次的enq:TX - row lock contentio，每次平均耗时0.5s， 100~200个session等在enq: TX 和gc buffer busy上很壮观哦！
3>案例三-gcs resource directory to be unfrozen真实案例
gcs resource directory to be unfrozen与DRM 有直接关系
4>案例四- gc cr block lost真实案例
Ierrs is the number of received packets that the system recognized as being corrupted.
Global Cache问题一定要和OS和Network层结合起来看， ifconfig、
netstat、 syslog信息极易获得， nmon、 osw亦有价值
5>案例五- gc buffer busy acquire案例
RAC负载均衡下并发insert很容易造成gc buffer busy acquire
本实例第一个申请该current block时进入gc current request，本实例后续其
他进程若又发起对该current block的申请则均进入’gc buffer busy acquire’
等待。
11g后gc buffer busy分成 ’gc buffer busy acquire’ 和 ’gc buffer busy
release了
Bug 12595929 : GC BUFFER BUSY ACQUIRE CAUSING TOO SLOW
PERFORMANCE DURING INSERTS IN 11.2.0.2.2
6>案例六-gc buffer busy release/acquire案例
Redo flush慢造成的gc buffer busy release/acquire
七、cpu信息
Sockets:物理CPU个数
Cores :CPU核数:一个物理CPU可以对应多个core
CPUS : 逻辑CPU总个数(当硬件线程技术打开时,此时一个CPU core被视作2个或更多个逻辑CPU)
“Load Average” begin/end值代表CPU的大致运行队列大小。上图中快照开始到结束，平均 CPU负载增加了。
%User+%System: 总的CPU使用率，在这里是29.0%
%Total CPU:该实例所使用的CPU占总CPU的比例 🡺 % of total CPU for Instance
%Busy CPU:该实例所使用的Cpu占总的被使用CPU的比例 🡺 % of busy CPU for Instance
例如：
共4个逻辑CPU，其中3个被完全使用， 3个中的1个完全被
该实例使用，则%Total CPU= ¼ =25%，而%Busy CPU= 1/3= 33%。
当CPU高时一般看%Busy CPU可以确定CPU到底是否是本实例
消耗的，还是主机上其他程序。
% of busy CPU for Instance=
（ DB CPU+ background cpu time) /(BUSY_TIME /100)= (250,777.19 +7,195.70)/ (33,448,718/100)= 77.1%
% of total CPU for Instance=
（ DB CPU+ background cpu time) /
((BUSY_TIME+IDLE_TIME) /100)= (250,777.19 + 7,195.70)/
((33,448,718+81,844,586/100)= 22.4%
%DB time waiting for CPU (Resource Manager)=
(RSRC_MGR_CPU_WAIT_TIME/100)/DB_TIME= (138,776,449/100)/(61,052
* 60)= 37.88%
Time Model Statistics Operating System Statistics
八、Operating System Statistics
数据来源于V$OSSTAT🡺DBA_HIST_OSSTAT，
TIME相关的指标单位均为百分之一秒
Busy_Time=SYS_TIME+USER_TIME
AVG_BUSY_TIME= BUSY_TIME/NUM_CPUS
BUSY_TIME + IDLE_TIME = ELAPSED_TIME *
CPU_COUNT=299.7*60*64=1150848s=(33,448,718+81,844,586)/100
OS_CPU_WAIT_TIME 🡺进程等OS调度， cpu queuing
九、Memory Statistics
11g以后才有的一个section，可以了解SGA、 PGA、主机物理内存的大致使用情况。
如上例PGA在快照时间内从23677MB增长到26301MB, pga_aggregate_target=16GB，存在overalloc（倒数第二列），建议26G
% Host Mem used for SGA+PGA 可以大致反映本实例占用主机物理内存的情况。
注意Host Mem也可能起伏，如使用DLPAR时
十、Time Model Statistics
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（无法分配shared pool）
• hard parse (sharing criteria) elapsed time 由于无法共享游标造成的硬解析
• hard parse (bind mismatch) elapsed time 由于bind type or bind size 不一致造成的硬解析
十一、Foreground Wait Class
十二、RAC Statistics
1、纵览RAC AWR
如果发现top 5里面有集群等待就去看 “RAC Statistics”
Global Cache Load Profile
Global Cache Efficiency Percentages (Target local+remote 100%)
Global Cache and Enqueue Services - Workload Characteristics
gc cache 和队列服务--工作量特性
Global Cache and Enqueue Services - Messaging Statistics
gc cache 和队列服务--消息统计
global cache的等待事件
3、Global Cache Load Profile
Estd Interconnect traffic (KB)：内网卡通讯量，40M/s算非常高，重点关注，80M/S是极限，少的系统可能不到1M
真实大型SIEBEL应用的一个例子， 0.03%的的逻辑读由其他节点上的缓存满足。
Global Cache Receive/server的原因一般是节点间缓存争用或本地无此缓存
(received+send)*db_block_size= 901 * 8k= 7.04MB/s= 56.32Mb/s
注意这仅仅是粗略估算，一般建议private network选用10Gb带宽
一条GCS/GES Message大约200 bytes
4、Global Cache and Enqueue Services
Avg global cache cr block receive time (ms):0.7
Avg global cache current block receive time (ms):1.0
Avg global cache cr block receive time (ms)= 10 * gc cr block receive time / gc cr blocks received =10*458/4995=0.91
Avg global cache current block receive time (ms)= 10 * gc current block receive time / gc current blocks received=10*740/4005=1.84
本地Time to process CR block request in the cache=异地(build time + flush time + send time)
本地Time to process current block request in the cache=异地(pin time + flush time + send time)
至关重要的2个指标，结合其他节点的AWR报告一起分析这2个指标， 一般要求小于2ms
若在RAC实例之间这2个指标差异很大，一般说明interconnect问题出现于OS buffer层或者网卡上
对RAC而言response time响应时间的要求比单节点更高，所以别指望用烂硬件搭出来的RAC性能比单机好 ☺ !
如果Interconnect的网络延迟 > IO子系统的延迟，那么RAC本身就是性能瓶颈。IO响应时间对RAC也非常重要，因为log file sync慢会造成 gc buffer busy等待：
log file sync慢=>commit慢， commit慢=>释放 行锁慢=》rac flush redo慢，从而出现gc buffer busy release/acquire，前后相互作用🡺 enq:TX 大幅出现
Avg global cache cr block receive time (ms)
//cr 一致读
该指标反映平均每个global cr块从申请到收到的耗时
Avg global cache cr block receive time (ms)
= 10 * gc cr block receive time / gc cr blocks received
= 228,252 / 134,978 * 10 = 16.91ms
Time to process CR block request in the cache
= (build time + flush redo time + send time)
相关指标（对端看这三个指标）：
• gc cr block flush time
• gc cr block build time
• gc cr block send time
2>Avg global cache current block receive time (ms):
该指标反映平均每个global current块从申请到收到的耗时
Avg global cache cr block receive time (ms)
= 10 * gc current block receive time / gc current blocks received
= 116,862 / 790,899 * 10 = 1.47ms
Time to process current block request in the cache
= (pin time + flush time + send time)
相关指标（对端看这三个指标）：
•gc current block pin time
•gc current block flush time
•gc current block send time
3>Workload Characteristics
Avg message sent queue time 一条信息进入队列到发送它的时间
Avg message sent queue time on ksxp 对端收到该信息并返回ACK的时间，这个指标很重要，直接反应了网络延迟，一般小于1ms
Send message有2种方式：
kjccsmg() – send message (FG direct send)—直接发送，越大越好
kjccqmg() – queue message (indirect send by LMS)-由LMS间接发送
% of indirect sent messages 🡺
间接发送信息一般是排序或大的信息，流控制也可能引起indirect sent message
% of flow controlled messages 🡺
流控制最常见的原因是网络状况不佳，% of flow controlled messages应当小于1%
流控类似机场的流量控制：，下面情况可能导致流控：
- 私网网络链路不顺畅
- RAC 对端节点负载很高
- 两个节点的节点传输配置有差异
ave message sent queue time on ksxp(ms)下正常情况下小于1毫秒：如果比较大，可能是CLUSTER INTERCONNECT出现了问题。
做ipc诊断：
oradebug setmypid
oradebug ipc
oradebug tracefile_name
看看如下这句话中的IP是否正确
1）如果网络配置没有问题，可以检查一下TCP 和UDP的buffer是否不足
root#netstat -s | grep overflow 值为了0一般情况下。
root#netstat -i
2)ps aux | grep lms
查看是否是有某些表产生了过多的global cr request
select STATISTIC_NAME stat,
OWNER,
OBJECT_NAME obj,
sum(value) val
from v$segment_statistics
where STATISTIC_NAME like 'global%'
and value > 10000
group by STATISTIC_NAME,OWNER,OBJECT_NAME
order by val desc;
2、select CR_REQUESTS cr,
CURRENT_REQUESTS cur,
DATA_REQUESTS data,
UNDO_REQUESTS undo,
TX_REQUESTS tx
from v$cr_block_server;
查看一段段时间内，CR的值是否很大。
十二、event事件关联
在rac环境中rac flush redo会受到写redo慢的影响，从而出现gc buffer busy release/acquire。
redo flush是Oracle为了保证Instance Recovery实例恢复机制，而要求每一个current block在本地节点local instance被修改后，必须要将该current block相关的redo 写入到logfile 后（要求LGWR必须完成写入后才能返回)，
才能由LMS进程传输给其他节点使用。RAC 的Redo flush慢造成gc buffer busy release/acquire等待
- log file sync 慢造成行锁和gc busy：
log file parallel write慢=> log file sync慢=>commit慢， commit慢=>释放行锁慢，在rac环境中rac flush redo也受到写redo慢的影响，从而出现gc buffer busy release/acquire，前后相互作用=》enq:TX 大幅出现
- gc busy wait单独出现：
gc buffer busy造成的最根本原因是跨实例访问大量的buffer cache
- 减少跨实例访问buffer；把客户端连接数据库的串从负载修改成主备
- 优化sql，减少sql的逻辑读
