CPU states: 96.0% idle, 0.3% user, 2.6% kernel, 1.1% iowait, 0.0% swap

　　Memory: 4096M real, 2660M free, 1396M swap in use, 3013M swap free

　　PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND

　　11928 a21562 1 0 0 3008K 2496K cpu/1 0:02 1.12% top

　　14965 mpgj76 4 59 0 10M 3696K sleep 3:09 0.18% view_server

　　当时现场数据显示：iowait 值与以前相比大很多， 没有异常进程

　　2. sar –d (输出为实验室数据，仅作格式参考)

　　SunOS sc19 5.7 Generic_106541-42 sun4u 03/20/08

　　00:00:00 device %busy avque r+w/s blks/s avwait avserv

　　sd410 17 0.4 50 1628 0.1 7.1

　　sd410,a 0 0.0 0 0 0.0 0.0

　　sd410,b 0 0.0 0 0 0.0 0.0

　　sd410,c 0 0.0 0 0 0.0 0.0

　　sd410,g 17 0.4 50 1628 0.1 7.1

　　当时现场数据显示，放数据文件的设备 avwait, avque, blks/s值偏大

　　第五步, 察看数据库的等待事件

　　一个大业务量的数据库如果性能不好的话, 一般来说都会有大量的等待事件, 上百个等待事件很常见, 我通常会按照EVENT进行group.

　　Select count(*), event from v$session_wait where event not in ('smon timer','pmon timer','rdbms ipc message','SQL*Net message from client') group by event order by 1 desc;

　　输出结果显示最多的等待事件是buffer busy waits。

　　进一步分析，找出等待的原因

　　Select count(*), p1, p2, p3 from v$session_wait where event = ‘buffer busy waits’ group by p1,p2,p3;

　　在buffer busy waits等待事件中