ITPub博客

首页 > 数据库 > Oracle > ORACLE 11.2.0.4 for HPUNIX 业务SQL处理数据量变化导致的CPU使用率超标触发告警

ORACLE 11.2.0.4 for HPUNIX 业务SQL处理数据量变化导致的CPU使用率超标触发告警

原创 Oracle 作者:清风艾艾 时间:2018-09-29 22:19:49 0 删除 编辑

    某客户oracle 11.2.0.4 rac for HPUNIX系统,由于业务SQL处理的数据量变化导致的CPU使用率超标,引起告警。

一、问题描述

     2018 9 22 日, 2:50:00 核心库的 CPU 使用率达到 87% 触发告警。

二、提取的分析日志

 提取数据库问题时段数据库告警日志; 取数据库 2018 9 22 1:00:00~2:00:00 2:00:00~3:00:00 awr 及其对比;取数据库 2018 9 22 1:00:00~2:00:00 2:00:00~3:00:00 的的 OSW 并生成图表观察 2 个时间点的 CPU 使用情况进行对比。

三、问题分析

  1、oswatch 提取 CPU 使用率相关对比

2018-9-21 1:00:00~3:00:00 2018-9-22 1:00:00~3:00:00

根据 2018-9-21~22 1:00:00~3:00:00 系统使用率对比,确定 2018-9-22 1:30:00~2:00:00 ,系统的 CPU 使用率接近 90%

 2、对比 2018-9-21~22 1:00:00~2:00:00 两个时间段的 awr

    2.1 数据库 2018-9-21~22 1:00:00~2:00:00 两个时间的 DBTIME 对比

 从数据库 dbtime 对比, 2018-9-21 1:00:00~2:00:00 dbtime 指标值是 3923 2018-9-22 1:00:00~2:00:00 dbtime 指标值是 4230 ,相差 300 并不算太多。

    2.2 2018-9-21~22 1:00:00~2:00:00 两个时间的 LOAD PROFILE 对比

 

2018-9-21 1:00:00~2:00:00 loadprofile parses 指标值高达 337 每秒, 2018-9-22 1:00:00~2:00:00 loadprofile parses 指标值只有 21.2 2018-9-21 1:00:00~2:00:00 loadprofile Hard parses 指标值高达 154 每秒, 2018-9-22 1:00:00~2:00:00 loadprofile parses 指标值只有 10.7 loadprofile 对比可知, 2018-9-22 1:00:00~2:00:00 ,硬解析比较严重,硬解析严重会导致 latch 争用事件,引起数据库服务器 CPU 飙高。

  2018-9-21 1:00:00~2:00:00 数据库顶级等待事件对比, 2018-9-22 1:00:00~2:00:00 等待事件 latch:row cache objects latch:cache buffers chans 严重,吻合 loadproile 中硬解析相关指标 Hard parses parses 高的情况。

  2.3 数据库顶级等待事件对比

  2018-9-21~22 1:00:00~2:00:00 数据库 TOP SQL ordered by Elapsed Time 对比, 2018-9-22 1:00:00~2:00:00 数据库自动任务 SQL tunning Advisor 激活并占用比较多的 CPU 资源。 

   2.4 2018-9-21~22 1:00:00~2:00:00 两个时间对比发现的问题 SQL

    2018-9-22 1:00:00~2:00:00 时段有一条 SQL 语句占用 CPU 比较突出: 1 小时内执行 5645 次,每次执行平均耗时 14.56

  af535njf3m8fv

select * from adkmx where ((((faredm=:b0 and jiluzt='0') and yngyjg=:b1) and jioyrq=:b2) and joyisj='LN_JIEX') order by HUOBDH, DAIKZH, MXXHAO

    

      对比 af535njf3m8fv 的执行历史,发现 2018-9-22 日,该 sql 语句 fetch 的数据量 394304 比平时的 6300 多了近 70 倍,行处理 776277 比平时 1400 多了近 554 倍, cpu 消耗 54548.460 比平时的 700 多近 80 倍,这是 af535njf3m8fv 在执行时 CPU 消耗过高的真正原因。

四、问题总结

     1 af535njf3m8fv 2018-9-22 fetch 的数据量 394304 比平时的 6300 多了近 70 倍,行处理 776277 比平时 1400 多了近 554 倍, cpu 消耗 54548.460 比平时的 700 多近 80 倍,是 af535njf3m8fv 在执行时 CPU 消耗过高的真正原因。

2 、另外, 2018-9-22 1:00:00~2:00:00 相比正常时段 2018-9-21 1:00:00~2:00:00 ,数据库的硬解析比较突出。导致硬解析严重的原因是,应用的部分 sql 语句没有使用绑定变量,数据库没有关闭 sql 自适应游标共享。

       3 2018-9-22 1:00:00~2:00:00 相比正常时段 2018-9-21 1:00:00~2:00:00 ,数据库有 SQL TUNNING ADVISOR 自动维护任务执行,并且消耗比较高的 CPU 资源。

五、建议

  1、   请甲方老师联系业务评估 SQL( af535njf3m8fv ) 处理数据量的合理性,避免数据库服务器夯死;

  2、   数据库关闭 sql 游标共享;

  3、   调整应用 sql 语句使用绑定变量;

 4、关闭数据库 STA SQL Tunning advisor );















来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29357786/viewspace-2215301/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
个人喜欢IT行业,目前从事数据库工作,包括Oracle、mysql、mongodb、sqlserver等数据库的维护,喜欢专研开发技术,尤其对java程序的开发感兴趣。工作经历上,在中国联通系统集成公司、中公网医疗信息技术有限公司做过数据库技术支持;目前在海量数据,负责华东区oracle、mysql、mongodb的维护工作。

注册时间:2015-01-30

  • 博文量
    176
  • 访问量
    204097