top,vmstat,free过后发现系统较为空闲状态，抓statspack：

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 1,312M Std Block Size: 16K
Shared Pool Size: 448M Log Buffer: 1,024K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 103,989.15 5,199.31
Logical reads: 4,307.61 215.37
Block changes: 670.76 33.54
Physical reads: 6.72 0.34
Physical writes: 14.18 0.71
User calls: 329.68 16.48
Parses: 128.77 6.44
Hard parses: 8.52 0.43
Sorts: 18.64 0.93
Logons: 0.03 0.00
Executes: 320.35 16.02
Transactions: 20.00

% Blocks changed per Read: 15.57 Recursive Call %: 55.47
Rollback per transaction %: 2.37 Rows per Sort: 21.30

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.88 Redo NoWait %: 99.99
Buffer Hit %: 99.84 In-memory Sort %: 100.00
Library Hit %: 97.90 Soft Parse %: 93.38
Execute to Parse %: 59.80 Latch Hit %: 99.93
Parse CPU to Parse Elapsd %: 98.16 % Non-Parse CPU: 89.86

因应用改动起来太大一直没有使用绑定变量，软解析不高，目前强制cursor_sharing为force，shared_pool_size有些偏大，在线将其改小这种做法当然不可取，db_cache_size在后面的advice看起来处于合适大小状态。

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
global cache cr request 147,324 698 19.66
buffer busy global CR 7,435 682 19.22
global cache null to x 85,665 613 17.27
CPU time 574 16.17
buffer busy global cache 8,012 221 6.22

从owi方面看起来是符合之前讲的主要issue为buffer busy waits及RAC相关的wait的。

分析：

目前MLB21上的主要等待事件为buffer busy wait，等待类别为data block，实际上因data block而触发的buffer busy wait等待事件下面两类： 1、一种是高并发会话在对相同的对象执行DML，同时db_block_size尺寸较大(因同一个块包含更多的行)

从抓取到的二条TOP合此类型(UPDATE&INSERT)，较为合适的方法就是增大PCTFREE。

2、另外就是多个session并发请求相同的数据块，但因该数据块不在buffer_cache中而必须从磁盘读取，处理这种情况，oracle会只让其中一个sesion进行磁盘读取，此时其它session等待块从磁盘上读取进buffer_cache而抛出buffer busy wait等待事件。

这种情况也存在于当前环境中，从抓取到的第3条语句，表现为执行较为频繁且伴随有db file sequential read等待事件，可以先试着先优化TOP N逻辑读的SQL。

再比对一下，发现导致buffer busy wait的SQL语句与导致cluster wait的SQL语句一模一样。

于是问题清晰了，当前DB环境的block_size为16k，RAC环境下的OLTP再加上那几个超频繁被执行update、insert的大表操作下，显得有些惨不忍睹，当前那几个表的pctfree为10，准备加大到30左右，index的pctfree低于50会导致索引走范围扫描，且快速全局扫描会较慢。
上面提到的第2种buffer busy waits会造成少量的db file scattered read(即oracle允许其中一个session去磁盘读取数据块，当然，这个动作也有可能是db file sequential read)和大量的db file sequential read(即其他session会对读进来后的数据块进行逻辑读取)，需要去调优statspack中的TOP N的逻辑读。