数据库CPU资源使用率高问题分析

1. 问题概述
   2021年3月25日，业务反馈数据库运行缓慢，执行sql耗时长。数据库版本：12C
2. 问题分析
   登陆数据库主机发现，数据库主机的CPU资源比较繁忙，CPU使用率高达90%。
   select ta.,round(ta.cpu_time/tb.total_cpu * 100,1) cpu_usage from
   (select s.username,s.program,s.event,s.sql_id,sum(trunc(m.CPU)) CPU_TIME,count() sum
   from v$sessmetric m ,v$session s
   where ( m.PHYSICAL_READS >100
   or m.CPU>100
   or m.LOGICAL_READS >100)
   and m.SESSION_ID = s.SID
   and m.SESSION_SERIAL_NUM = s.SERIAL#
   and s.status = ‘ACTIVE’
   and username is not null
   group by s.username,s.program,s.event,s.sql_id
   order by 5 desc) ta,(select sum(cpu) total_cpu from v$sessmetric) tb
   where rownum < 11;
   
   确定SQL涉及的具体表后查询表的统计信息收集情况，发现表的统计信息为0，实际表中存在大量数据。
   select t.owner, t.table_name, t.LAST_ANALYZED, t.NUM_ROWS
   from dba_tables t
   where t.LAST_ANALYZED > to_date(‘2021-03-24’, ‘yyyy-mm-dd’)
   order by t.last_analyzed desc;
   查看执行计划是否出现改变
   select distinct sql_id, t.PLAN_HASH_VALUE, t.TIMESTAMP
   from dba_hist_sql_plan t
   where sql_id in (‘28r5y1pz5b3fm’,
   ‘as7xmp3urjqk1’,
   ‘d9cxmr01ht4u7’,
   ‘63hk47scqj261’,
   ‘4490vrb5m8v0w’,
   ‘90rts5thg3zv3’)
   order by sql_id, t.TIMESTAMP;
   在3月25日之后，涉及高消耗CPU的sql执行计划均发生改变
   

那么SQL为什么会改变了执行计划呢？
select OWNER,
TABLE_NAME,
TO_CHAR(T.STATS_UPDATE_TIME, ‘YYYY-MM-DD HH24:MI’)
from dba_tab_stats_history T
where table_name = ‘表名’;

3月24日23点该表收集了统计信息。查看数据库是否运行了自动统计下信息收集任务

SELECT a.JOB_NAME,
to_char(a.ACTUAL_START_DATE, ‘YYYY-MM-DD HH24:MI’),
a.RUN_DURATION,
a.STATUS
FROM dba_scheduler_job_run_details a
WHERE a.JOB_NAME LIKE ‘ORA$AT_SQ_SQL%’
ORDER BY A.ACTUAL_START_DATE DESC;

3. 问题处理
通过sqlt中的脚本coe_xfr_sql_profile.sql 将上述sql执行计划固定
@coe_xfr_sql_profile.sql
sql_id:xxxxxxx

sql_plan_hash1:sql执行时间1
sql_plan_hash2:sql执行时间2
sql_plan_hash：输入sql执行时间短的sql
脚本自动生成绑定脚本。
@生成的绑定脚本即可。