记录一次Oracle生产系统AWR报告分析

日常巡检数据库服务器时发现了一台服务器从昨晚开始到目前CPU使用率高达95%以上，马上登录上去看了下导出了一份AWR报告发现了几个问题与大家分享一下。

 

导出AWR报告之后肯定先看DB time，因为是CPU 8个核心所以DB time 477分钟算非常高了，基本上CPU都在95%以上。

接着看了下profile

发现逻辑读、物理读还有IOPS这块都非常高，每秒22G的逻辑读1.8G的物理读将近15W的IOPS，用iostata查了下，幸好存储性能非常好才占用了30%左右（因为存储这块不归我管，我也不知道存储是不是用了SSD）。

发现这些问题之后我心里就有底了，大概率是SQL问题，接着马上看了下后台等待事件

果然不出所料，单快读、多快读等待事件是排在最上面顺带还有什么直接路径读和read by other session，单快读和多快读等待事件很常见这个就不用说了直接去检查SQL或者增加相应的索引。我查了下read by other session发现是会话抢读造成，同时伴随单快读、多快读等待事件，所以直接找到这几个会话的SQL优化

接着就开始定位具体的SQL，继续往下看

第一条SQL是查询语句执行次数是0意味着执行了一个多小时还没执行完，这条语句肯定要抓出来看看对应的执行执行计划，后面的几条update肯定也是有问题的

然后又看了下使用IO较多的SQL，果然还是那几条。。然后点开这几条SQL发现都是在update TB_FOC_I_FLIGHT_INFO、TB_FLIGHT_DYNAMIC等几张表

其中很多SQL都是表嵌套的方式来关联更新，1个小时更细了3W次所以性能瓶颈很大。

看到这里这次的性能问题就解决了，剩下的就是反馈给开发给开发叫他们整改实在改不了我在出手，但是这个库我仔细看了还有几个小问题。

内存设置太小，服务器有32G上面只部署了一个数据库居然连30%的内存都没给到，直接给个80%都没问题，把buffer cache增大了在说！

还有这个审计表居然是段等待最高的，说明数据库强制审计了很多对象到该表，如果用不到审计其实关闭。

ITL事务槽等待，这个对象需要重点关注。