oracle 诊断案例 ：因应用死循环导致的cpu过高 -m6米乐安卓版下载

背景

  从08月21号应用上了新功能以后，cpu idle time 从95%左右断崖式下降至75%左右，到08-30空闲恢复到90%左右，后面又开始降下来了，因为报警阀值为50%，所以一直也没有关注到。
  报警突然在上周六晚上23点左右报警低于50%，不过一会就恢复了，当时也没有太在意，因为知道这个点数据库有跑批任务，偶尔有cpu负载很正常（dba的警觉，松懈了），后来在白天也开始断断续续的报了起来，自己才觉得不对劲。于是才打开电脑查看了下zabbix 监控报警如下图，发现了上述的现象，当时惊出一身汗啊，照这样下去，数据库服务器离挂不远了啊。

解决过程

  根据zabbix监控时间段生成了awr报告，db cpu 占用数据库100%。

发现问题：

sql_id : 6pkaqzmtgz3za 1小时内执行了27,720,222次；
sql_id : cvaz34tbf38xn 1小时内执行了1,358,576次；
sql_id : d54w1bhvhsbmk 1小时内执行了1,358,555次；
sql_id : 6f8v7rj4xmzgp 1小时内执行了5,579,817次；
内心想法：这四条sql这是要疯了差不多1s执行45万次，这是什么业务这么猛

  因为这4条sql的单次耗时都是0.几秒，所以基本不用考虑sql优化的问题。于是我把这4条sql情况邮件扔给了开发人员，并提醒了一句：“请尽快解决，目前cpu负载50%-60%，可能会影响数据库的响应速度，随时有宕机的风险”，这句很关键。
  邮件发出去以后，引起了领导的重视，让开发尽快确认问题…(此次省备n个字)
  最终发现程序逻辑有个bug,对处理过的数据状态未做修改，使程序重复处理相同的数据，造成了死循环。

修复后的cpu idle time 情况：

总结：

  作为dba对监控的敏感度一定不能松懈，这次幸亏发现的早，一个逻辑死循环很容易把数据库跑死。awr报告巡检每周最少一次，及时发现性能sql，把问题及时掐灭在萌芽中。。。。第一次经验总结，希望自己能坚持下去。。。。
                         文章推荐