数据库服务器CPU突然持续100%后自动下降原因诊断 - 数据库编程

1、CPU接近100% nmon数据

8月5日在9：20—9：40之间，出现CPU接近100%的情况，特点表现为9：20左右CPU急剧攀升，在9：45左右又快速下降

2、原因分析结果总述

2.1 持续时间与恢复方式

此次CPU攀高时间持续约20分钟，在无人工干预的情况下自动恢复

2.2 原因分析总述：

经过分析，原因为：4条SQL语句ORACLE优化器对LB_T_XXXVIDER视图、LB_T_XXXJECT_PROVIDER表、LA_XXCKAGE表的基数数据评估发生了巨大的差错，导致选择了错误的执行计划，消耗大量的CPU资源

2.3 错误执行计划估算数据与正确执行计划估算数据对比

此处为选择一条最严重的SQL语句为例，其它语句原因相同

错误执行计划基数估算值

Execution Plan

正确执行计划基数估算值

Execution Plan

Id	Operation	Name	Rows	Bytes	Cost (%CPU)
0	SELECT STATEMENT	?	?	?	64460 (100)
1	COUNT STOPKEY	?	?	?	?
2	VIEW	?	224K	38M	64460 (1)
3	SORT ORDER BY STOPKEY	?	224K	28M	64460 (1)
4	HASH UNIQUE	?	224K	28M	58849 (1)
5	FILTER	?	?	?	?
6	HASH JOIN OUTER	?	224K	28M	53237 (1)
7	NESTED LOOPS	?	?	?	?
8	NESTED LOOPS	?	347	29842	528 (0)
9	TABLE ACCESS BY INDEX ROWID	LB_T_XXXJECT_PROVIDER	347	21167	181 (0)
10	INDEX RANGE SCAN	IDX_PROJECT_PROVIDER_COMB1	182	?	4 (0)
11	INDEX UNIQUE SCAN	PK_LA_XXCKAGE	1	?	0 (0)
12	TABLE ACCESS BY INDEX ROWID	LA_XXCKAGE	1	25	1 (0)
13	VIEW	LB_T_XXXVIDER	9125K	409M	52700 (1)
14	HASH JOIN OUTER	?	9125K	556M	52700 (1)
15	TABLE ACCESS FULL	XXCC_SUPPLIER	26139	1148K	404 (0)
16	VIEW	?	6283K	113M	52287 (1)
17	SORT GROUP BY	?	6283K	185M	52287 (1)
18	TABLE ACCESS FULL	XXCC_SUPPLIER_CONTACT	10M	309M	148 (9)
cardinality feedback used for this statement

说明上面统计信息与实际数据存在非常大的差异，是引起执行计划错误的真正原因

2.4 错误执行计划与正确执行计划CPU资源消耗差异巨大对比

此处为选择一条最严重的SQL语句为例，其它语句比例相近

SQL ID: bj75p9188y410

错误执行计划CPU消耗是最优执行计划CPU消耗的348倍

2.5 问题自动修复原因

ORACLE11G 的新功能cardinality feedback可以在上次运行完成后，得到上一次运行的基数真正结果，智能的调整后面语句运行时的执行计划，通过cardinality feedback功能得到准确基数数据后调整的执行计划，会给出下面提示：

cardinality feedback used for this statement

3、数据库时间与AWR快照对应信息

此在列出时间与AWR快照对应信息的原因为后续分析依赖时间与快照的关系，展示阶段性数据

4、

数据库服务器CPU突然持续100%后自动下降原因诊断(一)