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

2015-02-02 20:38:27 · 作者: · 浏览: 17
总体原因具体分析

8月5日9:00—10:00AWR报告分析

SQL ordered by CPU Time

NO

CPU Time (s)

Executions

CPU per Exec (s)

Elapsed Time (s)

%CPU

%IO

SQL Id

SQL Text

1

2,927.66

12

243.97

4,589.72

63.79

0.00

bj75p9188y410

select * from ( select distinc...

2

1,771.52

3,820

0.46

2,660.05

66.60

0.00

gwz243zx18jk0

SELECT * FROM PUB_STRU_TYPE_RE...

3

1,687.68

6

281.28

1,981.37

85.18

0.00

gmfktzfsd6hj3

select * from ( select row_.*,...

4

1,320.77

18

73.38

2,050.40

64.42

0.00

1d44jc4at7xt6

select count(0) from ( select ...

5

870.33

745

1.17

1,288.11

67.57

0.00

4x0jsx8xmrq3c

select count(1) rcount from ( ...

6

856.20

63

13.59

1,096.32

78.10

0.00

1ztsa8nc1arn1

SELECT DISTINCT RFX2.rootId F...

7

752.07

429

1.75

1,145.77

65.64

0.00

9rpn6kmf9vwwh

select p.package_id, p.package...

8

729.02

94

7.76

853.01

85.46

0.00

bq1x40gqtd1r3

SELECT DISTINCT RFX2.rootId F...

9

683.45

12

56.95

1,538.29

44.43

37.32

f760vj05hjpww

SELECT DISTINCT RFX1.rootId F...

10

595.38

2

297.69

632.09

94.19

0.00

fh86uz0ch9z9w

select count(0) from ( select ...

?

?

分析:

(1) 上述标红色语句共四条,其中第4条和第10条其实为同一条SQL语句

(2) 上述四条标红色SQL语句分析为最消耗CPU资源的语句

(3) 上述四条标红色SQL语句在出问题前都没有运行,基本都集中在9:00以后开始运行

(4) 上述标红色语句的问题有共同特性,都调用了LB_T_XXXVIDER视图、LB_T_XXXJECT_PROVIDER表、LA_XXCKAGE

(5) 上述标红色语句都是因为优化器对LB_T_XXXVIDER视图、LB_T_XXXJECT_PROVIDER表、LA_XXCKAGE表的基数数据评估发生了巨大的差错,导致选择了错误的执行计划,消耗大量的CPU资源,导致CPU接近100%

(6) 上述标红色语句都是在几次错误选择后有效的利用了ORACLE11g的新特性cardinalityfeedback功能,最终得到准确的基数数据,自行修正了执行计划

?

5、问题语句逐条剖析

5.1 第一条:SQL_ID:bj75p9188y410

SQL ID: bj75p9188y410

#

Plan Hash Value

Total Elapsed Time(ms)

Executions

1st Capture Snap ID

Last Capture Snap ID

1

3990363694

4,585,425

9

33676

33677

2

6178145

2,838

2

33677

33677

3

2354817963

1,461

1

33677

33677

分析:

(1)标红色的为错误的执行计划及其统计信息

(2)9:00—10:00之间,共发生9次错误的执行计划

(3)在前面发生9次错误的执行计划之后,由于ORACLE 11G的cardinality feedback新功能,最终得到准确的基数,在9:30-10:00之间,自动纠正了执行计划

?

5.2 第二条:SQL_ID:gmfktzfsd6hj3

SQL ID: gmfktzfsd6hj3

#

Plan Hash Value

Total Elapsed Time(ms)

Executions

1st Capture Snap ID

Last Capture Snap ID

1

617277444

2,602,874

6

33677

33678

2

2335536944

2,725

2

33678

33678

3

687995303

1,437

1

33678

33678

分析:

(1)标红色的为错误的执行计划及其统计信息

(2)9:30—10:30之间,共发生6次错误的执行计划

(3)在前面发生6次错误的执行计划之后,由于ORACLE 11G的cardinality feedback新功能,最终得到准确的基数,在10:00-10:30之间,自动纠正了执行计划

?

5.3 第三条:SQL_ID:1d44jc4at7xt6

SQL ID: 1d44jc4at7xt6

#

Plan Hash Value

Total Elapsed Time(ms)

Executions

1st Capture Snap ID

Last Capture Snap ID

1

3265929876

2,029,525

4

33676

33677

2

2949667951

19,116

13

33676

33677

3

1227972422

1,761

1

33676

33677

分析:

(1)标红色的为错误的执行计划及其统计信息

(2)9:00—10:00之间,共发生4次错误的执行计划,其中

(3)在前面发生4次错误的执行计划之后,由于ORACLE 11G的cardinality feedback新功能,最终得到准确的基数,在9:30-10:00之间,自动纠正了执行计划

?

5.4 第四条:SQL_ID:fh86uz0ch9z9w

SQL ID: fh86uz0ch9z9w

#

Plan Hash Value

Total Elapsed Time(ms)

Executions

1st Capture Snap ID

Last Capture Snap ID

1

3265929876

1,247,089

4

33676

33681

2

2949667951

2,624

2

33681

33681

3

1227972422

1,291

1

33681

33681

分析:

(1)标红色的为错误的执行计划及其统计信息

(2)9:00—11:30之间,共发生4次错误的执行计划,其中两次发生在9:00-9:30间

(3)在前面发生4次错误的执行计划之后,由于ORACLE 11G的cardinality feedback新功能,最终得到准确的基数,在11:00-11:30之间,自动纠正了执行计划

?

6、引发执行计划错误原因分析

6.1 表统计