前言 这两天一只对外提供查询的数据库CPU使用率频繁攀升到100%,客户记得焦头烂额,总希望我抓点sql让开发商优化。和客户通完电话后,我心里想到,这烂系统,抓几个sql顶什么用,问题早就提过好几次了,每次都不了了之,出了问题就知道在那瞎忙,找点表面问题修修补补,本质问题从来都是置之不理。一通抱怨后,开始逐步分析,人就是这样,吃人嘴软,谁让客户是上帝呢?抱怨归抱怨,工作还是要认认真真去对待的,分析报告如下,抛砖引玉,如有错误,望批评指正,谢谢!
分析报告 系统环境:AIX 6.1 Oracle 10g 10.2.0.5.4 查询库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 0.0 0.0 hdisk44 17 0.0 951 7609 0.0 0.2 hdisk46 0 0.0 10 87 0.0 0.2 hdisk47 0 0.0 0 0 0.0 0.0 hdisk48 0 0.0 0 0 0.0 0.0 hdisk45 0 0.0 0 0 0.0 0.0 hdisk49 0 0.0 0 0 0.0 0.0 hdisk50 0 0.0 0 0 0.0 0.0 hdisk51 0 0.0 0 0 0.0 0.0 hdisk52 0 0.0 0 0 0.0 0.0 hdisk53 0 0.0 0 0 0.0 0.0 hdisk54 0 0.0 0 0 0.0 0.0 hdisk55 0 0.0 0 0 0.0 0.0 hdisk57 7 0.0 487 3900 0.0 0.2 hdisk58 0 0.0 0 0 0.0 0.0 hdisk59 0 0.0 23 191 0.0 0.5 hdisk56 0 0.0 0 0 0.0 0.0 hdisk60 0 0.0 0 0 0.0 0.0 hdisk61 7 0.0 540 4322 0.0 0.2 hdisk62 0 0.0 0 0 0.0 0.0 hdisk63 0 0.0 0 0 0.0 0.0 hdisk64 0 0.0 0 0 0.0 0.0 hdisk65 0 0.0 0 0 0.0 0.0 hdisk66 0 0.0 0 0 0.0 0.0 hdisk68 0 0.0 0 0 0.0 0.0 hdisk69 0 0.0 0 0 0.0 0.0 hdisk67 0 0.0 0 0 0.0 0.0 hdisk71 0 0.0 0 0 0.0 0.0 hdisk70 0 0.0 0 0 0.0 0.0 hdisk74 0 0.0 0 0 0.0 0.0 hdisk76 0 0.0 0 0 0.0 0.0 hdisk77 0 0.0 0 0 0.0 0.0 hdisk78 0 0.0 0 0 0.0 0.0 hdisk75 0 0.0 0 0 0.0 0.0 hdisk73 0 0.0 0 0 0.0 0.0 hdisk80 0 0.0 0 0 0.0 0.0 hdisk81 0 0.0 0 0 0.0 0.0 hdisk82 0 0.0 0 0 0.0 0.0 hdisk79 0 0.0 0 0 0.0 0.0 hdisk84 0 0.0 0 0 0.0 0.0 hdisk72 0 0.0 0 0 0.0 0.0 hdisk83 0 0.0 0 0 0.0 0.0 hdisk87 0 0.0 0 0 0.0 0.0 hdisk88 0 0.0 0 0 0.0 0.0 hdisk89 0 0.0 0 0 0.0 0.0 hdisk86 0 0.0 0 0 0.0 0.0 hdisk92 0 0.0 0 0 0.0 0.0 hdisk85 0 0.0 0 0 0.0 0.0 hdisk93 0 0.0 0 0 0.0 0.0 hdisk90 0 0.0 0 0 0.0 0.0 hdisk94 0 0.0 0 0 0.0 0.0 hdisk91 0 0.0 0 0 0.0 0.0 hdisk96 0 0.0 0 0 0.0 0.0 hdisk98 0 0.0 0 0 0.0 0.0 hdisk95 0 0.0 0 0 0.0 0.0 hdisk99 0 0.0 0 0 0.0 0.0 hdisk100 0 0.0 0 0 0.0 0.0 hdisk97 0 0.0 0 0 0.0 0.0 hdisk101 0 0.0 0 0 0.0 0.0 hdisk102 0 0.0 0 0 0.0 0.0 hdisk103 0 0.0 0 0 0.0 0.0 hdisk105 0 0.0 0 0 0.0 0.0 hdisk106 0 0.0 0 0 0.0 0.0 hdisk107 0 0.0 0 0 0.0 0.0 hdisk104 0 0.0 0 0 0.0 0.0 hdisk109 0 0.0 0 0 0.0 0.0 hdisk110 0 0.0 0 0 0.0 0.0 hdisk111 0 0.0 0 0 0.0 0.0 hdisk113 0 0.0 0 0 0.0 0.0 hdisk114 0 0.0 0 0 0.0 0.0 hdisk108 0 0.0 0 0 0.0 0.0 hdisk115 0 0.0 0 0 0.0 0.0 hdisk112 0 0.0 0 0 0.0 0.0 hdisk117 0 0.0 0 0 0.0 0.0 hdisk118 0 0.0 0 0 0.0 0.0 hdisk119 0 0.0 0 0 0.0 0.0 hdisk116 0 0.0 0 0 0.0 0.0 hdisk121 0 0.0 0 0 0.0 0.0 hdisk122 0 0.0 0 0 0.0 0.0 hdisk123 0 0.0 0 0 0.0 0.0 hdisk125 0 0.0 0 0 0.0 0.0 hdisk120 0 0.0 0 0 0.0 0.0 hdisk124 0 0.0 0 0 0.0 0.0 hdisk128 0 0.0 0 0 0.0 0.0 hdisk126 0 0.0 0 0 0.0 0.0 hdisk127 0 0.0 0 0 0.0 0.0 hdisk131 0 0.0 0 0 0.0 0.0 hdisk132 0 0.0 0 0 0.0 0.0 hdisk129 0 0.0 0 0 0.0 0.0 hdisk130 0 0.0 0 0 0.0 0.0 hdisk134 0 0.0 0 0 0.0 0.0 hdisk135 0 0.0 0 0 0.0 0.0 hdisk133 0 0.0 0 0 0.0 0.0 hdisk136 0 0.0 0 0 0.0 0.0 hdisk138 0 0.0 0 0 0.0 0.0 hdisk139 0 0.0 0 0 0.0 0.0 hdisk140 0 0.0 0 0 0.0 0.0 hdisk137 0 0.0 0 0 0.0 0.1 hdisk141 0 0.0 0 0 0.0 0.0 hdisk143 0 0.0 0 0 0.0 0.0 hdisk144 0 0.0 0 0 0.0 0.0 hdisk142 0 0.0 0 0 0.0 0.0 hdisk147 0 0.0 0 0 0.0 0.0 hdisk148 0 0.0 0 0 0.0 0.0 hdisk149 0 0.0 0 0 0.0 0.0 hdisk146 0 0.0 0 0 0.0 0.0 hdisk145 0 0.0 0 0 0.0 0.0 hdisk4 0 0.0 0 0 0.0 0.0 hdisk12 0 0.0 0 0 0.0 0.0 hdisk11 0 0.0 0 0 0.0 0.0 hdisk17 0 0.0 0 0 0.0 0.0 hdisk6 0 0.0 0 0 0.0 0.0 hdisk0 0 0.0 0 0 0.0 0.0 hdisk1 0 0.0 0 0 0.0 0.0 hdisk2 0 0.0 0 0 0.0 0.0 可以看到虽然本机连接的磁盘有140 余块,但读写主要发生在disk18,disk22,disk44,disk57,disk61 。 了解Oracle RAC Brain Split Resolution集群脑裂协议缩小undo表空间全记录相关资讯 Oracle数据库
- Oracle数据库全球化 (03月01日)
- Oracle数据库日期过滤方法性能比较 (02/02/2015 13:20:26)
- Oracle数据库安装中端口被占用问题 (10/29/2014 07:42:24)
| - 在CentOS 6.6上搭建C++运行环境并 (10/10/2015 19:44:40)
- Oracle数据库无法使用localhost和 (11/14/2014 16:39:10)
- Oracle 多数据库的数据同时更新 (06/16/2014 21:52:23)
|
本文评论 查看全部评论 (0)