某客户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 ）；
