前言
这两天一只对外提供查询的数据库CPU使用率频繁攀升到100%，客户记得焦头烂额，总希望我抓点sql让开发商优化。和客户通完电话后，我心里想到，这烂系统，抓几个sql顶什么用，问题早就提过好几次了，每次都不了了之，出了问题就知道在那瞎忙，找点表面问题修修补补，本质问题从来都是置之不理。一通抱怨后，开始逐步分析，人就是这样，吃人嘴软，谁让客户是上帝呢？抱怨归抱怨，工作还是要认认真真去对待的，分析报告如下，抛砖引玉，如有错误，望批评指正，谢谢！
分析报告
查询库db2 2012-07-02 09:00~~10:00 AWR 报告
查询库db2 2012-07-04 11:00~~12:00 AWR 报告
通过以上等待事件的对比可以发现，CPU等待事件明显，同时都伴随着gc cr multi block request和db file sequential read等待事件。CPU等待事件与应用上表现出CPU占用率100%的现象相吻合。结合gc cr multi block request和db file sequential read事件明显这个因素，推测是由于节点之间频繁交换数据块(构造gc cr时所进行的请求和调度需要消耗CPU时间)和磁盘与内存直接频繁读写(内存的分配与撤销同样需要消耗CPU时间)。
查看磁盘信息如下
#sar -d 1
AIX fjlt_zgcx_db02 1 6 00F65AD44C00 07/04/12
System configuration: lcpu=32 drives=150 mode=Capped
11:56:31 device %busy avque r+w/s Kbs/s avwait avserv
11:56:32 hdisk3 0 0.0 0 0 0.0 0.0
hdisk5 0 0.0 0 0 0.0 0.0
hdisk10 0 0.0 0 0 0.0 0.0
hdisk16 0 0.0 0 0 0.0 0.0
hdisk7 0 0.0 0 0 0.0 0.0
hdisk9 0 0.0 0 0 0.0 0.0
hdisk14 0 0.0 0 0 0.0 0.0
hdisk13 0 0.0 0 0 0.0 0.0
hdisk8 0 0.0 0 0 0.0 0.0
hdisk15 0 0.0 0 0 0.0 0.0
hdisk18 23 0.0 792 6481 0.0 0.3
hdisk19 0 0.0 0 0 0.0 0.0
hdisk20 2 0.0 33 270 0.0 0.8
hdisk22 10 0.0 320 2563 0.0 0.5
hdisk23 0 0.0 0 0 0.0 0.0
hdisk24 0 0.0 0 0 0.0 0.0
hdisk21 0 0.0 0 0 0.0 0.0
hdisk25 0 0.0 0 0 0.0 0.0
hdisk26 0 0.0 0 0 0.0 0.0
hdisk27 0 0.0 0 0 0.0 0.0
hdisk28 0 0.0 0 0 0.0 0.0
hdisk29 0 0.0 0 0 0.0 0.0
hdisk30 0 0.0 0 0 0.0 0.0
hdisk31 35 0.0 1140 9122 0.0 0.4
hdisk32 0 0.0 0 0 0.0 0.0
hdisk33 0 0.0 5 47 0.0 0.2
hdisk34 0 0.0 0 0 0.0 0.0
hdisk35 0 0.0 0 0 0.0 0.0
hdisk36 0 0.0 0 0 0.0 0.0
hdisk37 0 0.0 0 0 0.0 0.0
hdisk39 0 0.0 0 0 0.0 0.0
hdisk40 0 0.0 0 0 0.0 0.0
hdisk41 0 0.0 0 0 0.0 0.0
hdisk38 0 0.0 0 0 0.0 0.0
hdisk42 0 0.0 0 0 0.0 0.0
hdisk43 0 0.0 0 0