公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2015-09-29 21:47:28 · 原文链接

一般在一些容灾环境中，尤其是在11g的ADG非常普及的场景下，备库被赋予了更多的责任，很多时候在容忍一些延迟的情况下，有些应用的大量数据查询任务直接放到了备库，把它当做一个只读节点来使用，所以在有些情况下，可能备库的压力还是蛮大的。
最近自从把备库纳入zabbix的监控体系之后，有一个备库总是在午夜发来一条报警邮件。内容大体如下：
adb0_s1@10.127.xx.xx_报警
————————————
报警内容: CPU utilization is too high
————————————
报警级别: PROBLEM
————————————
监控项目: CPU idle time：53.8 %
————————————
报警时间:2015.09.29-01:50:27
单纯从报警信息来看，这是一个备库中发出的报警，所以很自然联想到是有大量的批量查询任务在运行。
每次看到都直接忽略，看着最近的报警信息处理，多多少少都能发现点什么，就决定好好挖掘一下，看看有什么能改进的，目标就是不改动报警阀值，能够把负载控制在合理范围之内。

根据报警的时间点来抓取ash报告，前后浮动几分钟，这次没有连错就是备库，但是没有发现任何的信息，连top event都没有。
查看crontab，也没有发现任何相关的任务在运行。
自己都有点怀疑是不是CPU使用瞬间抖动造成的，是否为误报。貌似数据库层面没有很明显的发现，至少通过前后的几分钟时间来看，没有发现任何active session信息。我们来看看系统级的CPU使用情况，是否存在着明显的CPU过载现象。

蓝色部分是CPU使用的比例，在每天的凌晨到晚上6点都在满负荷运行，然后会有一些短暂的空闲期。每天都是如此。
所以CPU的过载问题是很明显而且有规律的。
第二天早上查看的时候，发现这个时间段还是在问题时间段之内，使用sar命令也确实能够看到CPU的使用率情况（最后一列）
01:20:01 AM 99.48
01:30:01 AM 93.70
01:40:01 AM 66.54
01:50:01 AM 47.29
02:00:01 AM 41.46
02:10:01 AM 38.30
02:20:01 AM 27.35
02:30:01 AM all 70.61 0.00 1.84 0.04 0.00 27.51
这个时候还是使用top命令来看，能够抓取到目前正在占用大量CPU资源的几个进程都是oracle用户进程。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1113 oracle 19 0 16.0g 9.1g 9.1g R 96.3 29.0 299:56.69 oracleadb0 (LOCAL=NO)
980 oracle 17 0 16.0g 9.1g 9.1g S 91.6 29.0 303:02.33 oracleadb0 (LOCAL=NO)
599 oracle 16 0 16.0g 9.2g 9.2g S 89.0 29.2 321:21.08 oracleadb0 (LOCAL=NO)
1313 oracle 16 0 16.0g 9.1g 9.1g R 88.0 29.0 290:09.17 oracleadb0 (LOCAL=NO)
982 oracle 15 0 16.0g 9.1g 9.1g R 86.7 29.0 302:18.63 oracleadb0 (LOCAL=NO)
884 oracle 17 0 16.0g 9.1g 9.1g R 85.7 29.0 308:39.81 oracleadb0 (LOCAL=NO)
拿出第一个进程分析，看看这个进程在干嘛。