P1 = file#

　　P2 = block#

　　P3 = id ( 此id对应为等待的原因)

　　按照p1,p2,p3 group是为了明确buffer busy waits的等待集中在哪些对象上。

　　Metalink对buffer busy waits等待事件的描述有如下一段话：

　　“If P3 shows that the "buffer busy wait" is waiting for a block read to complete then the blocking session is likely to be waiting on an IO wait (eg: "db file sequential read" or "db file scattered read" for the same file# and block#.”

　　输出结果显示，等待分布在多个不同的对象上，等待原因为 “waiting for a block read to complete”，进一步分析为IO的问题。

　　如果，buffer busy waits等待集中在某个对象上，说明有hot block, 通过重新rebuild这个对象增加freelist来解决,RAC环境增加freelist group.

　　通过以下SQL可以找到具体的object.

　　Select owner, segment_name, segment_type from dba_extents where file_id=P1 and P2 between block_id and block_id+blocks;

　　P1,P2是上面v$session_wait查出的具体的值

　　第六步, 明确原因，找出解决步骤

　　分析：

　　1。磁盘的IO流量增加

　　2。磁盘的IO等待增加

　　3。DB的IO流量没有增加

　　4。DB的IO等待增加

　　由1，2，3，4可以推出，有数据库以外的IO访问磁盘。

　　察看磁盘配置，该VG只存放了数据库数据文件和数据库系统文件。排除数据文件，产生IO的是数据库系统文件。

　　数据库系统文件一般来说不会产生IO, 有IO读写的地方只有log和dump文件。

　　结论：ora-7445产生的大量core dump文件堵塞IO

　　解决办法：

　　1，消除ora-7445. (应用不改的情况下，无法解决)

　　2, 把dump目录指向别的VG

　　3, 让oracle尽量少的去写core dump文件

　　background_core_dump = partial

　　shadow_core_dump = partial