国产99久久精品_欧美日本韩国一区二区_激情小说综合网_欧美一级二级视频_午夜av电影_日本久久精品视频

最新文章專題視頻專題問答1問答10問答100問答1000問答2000關(guān)鍵字專題1關(guān)鍵字專題50關(guān)鍵字專題500關(guān)鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專題關(guān)鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
當(dāng)前位置： 首頁 - 科技 - 知識百科 - 正文

數(shù)據(jù)庫服務(wù)器CPU突然持續(xù)100%后自動下降原因診斷

來源：懂視網(wǎng) 責(zé)編：小采 時間：2020-11-09 14:10:37
文檔

數(shù)據(jù)庫服務(wù)器CPU突然持續(xù)100%后自動下降原因診斷

數(shù)據(jù)庫服務(wù)器CPU突然持續(xù)100%后自動下降原因診斷:1、CPU接近100% nmon數(shù)據(jù) 8月5日在9：209：40之間，出現(xiàn)CPU接近100%的情況，特點表現(xiàn)為9：20左右CPU急劇攀升，在9：45左右又快速下降 2、原因分析結(jié)果總述 2.1 持續(xù)時間與恢復(fù)方式 此次CPU攀高時間持續(xù)約20分鐘，在無人工干預(yù)的情況下自動恢復(fù) 2.2 原因
推薦度：
導(dǎo)讀數(shù)據(jù)庫服務(wù)器CPU突然持續(xù)100%后自動下降原因診斷:1、CPU接近100% nmon數(shù)據(jù) 8月5日在9：209：40之間，出現(xiàn)CPU接近100%的情況，特點表現(xiàn)為9：20左右CPU急劇攀升，在9：45左右又快速下降 2、原因分析結(jié)果總述 2.1 持續(xù)時間與恢復(fù)方式 此次CPU攀高時間持續(xù)約20分鐘，在無人工干預(yù)的情況下自動恢復(fù) 2.2 原因

1、CPU接近100% nmon數(shù)據(jù) 8月5日在9：209：40之間，出現(xiàn)CPU接近100%的情況，特點表現(xiàn)為9：20左右CPU急劇攀升，在9：45左右又快速下降 2、原因分析結(jié)果總述 2.1 持續(xù)時間與恢復(fù)方式 此次CPU攀高時間持續(xù)約20分鐘，在無人工干預(yù)的情況下自動恢復(fù) 2.2 原因分析

1、CPU接近100% nmon數(shù)據(jù)

\

8月5日在9：20—9：40之間，出現(xiàn)CPU接近100%的情況，特點表現(xiàn)為9：20左右CPU急劇攀升，在9：45左右又快速下降

2、原因分析結(jié)果總述

2.1 持續(xù)時間與恢復(fù)方式

此次CPU攀高時間持續(xù)約20分鐘，在無人工干預(yù)的情況下自動恢復(fù)

2.2 原因分析總述：

經(jīng)過分析，原因為：4條SQL語句ORACLE優(yōu)化器對LB_T_XXXVIDER視圖、LB_T_XXXJECT_PROVIDER表、LA_XXCKAGE表的基數(shù)數(shù)據(jù)評估發(fā)生了巨大的差錯，導(dǎo)致選擇了錯誤的執(zhí)行計劃，消耗大量的CPU資源

2.3 錯誤執(zhí)行計劃估算數(shù)據(jù)與正確執(zhí)行計劃估算數(shù)據(jù)對比

此處為選擇一條最嚴(yán)重的SQL語句為例，其它語句原因相同

錯誤執(zhí)行計劃基數(shù)估算值

Execution Plan

Id

Operation

Name

Rows

Bytes

Cost (%CPU)

0

SELECT STATEMENT

315 (100)

1

COUNT STOPKEY

2

VIEW

1

180

315 (2)

3

SORT ORDER BY STOPKEY

1

151

315 (2)

4

HASH UNIQUE

1

151

314 (1)

5

FILTER

6

NESTED LOOPS OUTER

1

151

313 (1)

7

NESTED LOOPS

1

86

35 (0)

8

TABLE ACCESS BY INDEX ROWID

LB_T_XXXJECT_PROVIDER

1

61

34 (0)

9

INDEX RANGE SCAN

IDX_LB_T_XXXJECT_PROVIDER_003

183

3 (0)

10

TABLE ACCESS BY INDEX ROWID

LA_XXCKAGE

1

25

1 (0)

11

INDEX UNIQUE SCAN

PK_LA_XXCKAGE

1

0 (0)

12

VIEW PUSHED PREDICATE

LB_T_XXXVIDER

1

65

278 (1)

13

MERGE JOIN OUTER

1

64

278 (1)

14

TABLE ACCESS BY INDEX ROWID

XXCC_SUPPLIER

1

45

146 (0)

15

INDEX FULL SCAN

PK_XXCC_SUPPLIER

1

145 (0)

16

SORT JOIN

17998

333K

132 (2)

17

VIEW

17998

333K

131 (1)

18

SORT GROUP BY

17998

544K

131 (1)

19

TABLE ACCESS FULL

XXCC_SUPPLIER_CONTACT

30058

909K

130 (0)

正確執(zhí)行計劃基數(shù)估算值

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
    		•

    說明上面統(tǒng)計信息與實際數(shù)據(jù)存在非常大的差異，是引起執(zhí)行計劃錯誤的真正原因

    2.4 錯誤執(zhí)行計劃與正確執(zhí)行計劃CPU資源消耗差異巨大對比

    此處為選擇一條最嚴(yán)重的SQL語句為例，其它語句比例相近

    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

    錯誤執(zhí)行計劃CPU消耗是最優(yōu)執(zhí)行計劃CPU消耗的348倍

    2.5 問題自動修復(fù)原因

    ORACLE11G 的新功能cardinality feedback可以在上次運行完成后，得到上一次運行的基數(shù)真正結(jié)果，智能的調(diào)整后面語句運行時的執(zhí)行計劃，通過cardinality feedback功能得到準(zhǔn)確基數(shù)數(shù)據(jù)后調(diào)整的執(zhí)行計劃，會給出下面提示：

    cardinality feedback used for this statement

    3、數(shù)據(jù)庫時間與AWR快照對應(yīng)信息

    此在列出時間與AWR快照對應(yīng)信息的原因為后續(xù)分析依賴時間與快照的關(guān)系，展示階段性數(shù)據(jù)

    序號

    snap_id

    BEGIN_INTERVAL_TIME

    END_INTERVAL_TIME

    1

    33675

    05-8月 -13 08.30.41.054

    05-8月 -13 09.00.09.786

    2

    33676

    05-8月 -13 09.00.09.786

    05-8月 -13 09.30.10.502

    3

    33677

    05-8月 -13 09.30.10.502

    05-8月 -13 10.00.26.364

    4

    33678

    05-8月 -13 10.00.26.364

    05-8月 -13 10.30.18.791

    5

    33679

    05-8月 -13 10.30.18.791

    05-8月 -13 11.00.24.540

    4、總體原因具體分析

    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） 上述標(biāo)紅色語句共四條，其中第4條和第10條其實為同一條SQL語句

    （2） 上述四條標(biāo)紅色SQL語句分析為最消耗CPU資源的語句

    （3） 上述四條標(biāo)紅色SQL語句在出問題前都沒有運行，基本都集中在9：00以后開始運行

    （4） 上述標(biāo)紅色語句的問題有共同特性，都調(diào)用了LB_T_XXXVIDER視圖、LB_T_XXXJECT_PROVIDER表、LA_XXCKAGE

    （5） 上述標(biāo)紅色語句都是因為優(yōu)化器對LB_T_XXXVIDER視圖、LB_T_XXXJECT_PROVIDER表、LA_XXCKAGE表的基數(shù)數(shù)據(jù)評估發(fā)生了巨大的差錯，導(dǎo)致選擇了錯誤的執(zhí)行計劃，消耗大量的CPU資源，導(dǎo)致CPU接近100%

    （6） 上述標(biāo)紅色語句都是在幾次錯誤選擇后有效的利用了ORACLE11g的新特性cardinalityfeedback功能，最終得到準(zhǔn)確的基數(shù)數(shù)據(jù)，自行修正了執(zhí)行計劃

    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）標(biāo)紅色的為錯誤的執(zhí)行計劃及其統(tǒng)計信息

    （2）9：00—10：00之間，共發(fā)生9次錯誤的執(zhí)行計劃

    （3）在前面發(fā)生9次錯誤的執(zhí)行計劃之后，由于ORACLE 11G的cardinality feedback新功能，最終得到準(zhǔn)確的基數(shù)，在9：30-10：00之間，自動糾正了執(zhí)行計劃

    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）標(biāo)紅色的為錯誤的執(zhí)行計劃及其統(tǒng)計信息

    （2）9：30—10：30之間，共發(fā)生6次錯誤的執(zhí)行計劃

    （3）在前面發(fā)生6次錯誤的執(zhí)行計劃之后，由于ORACLE 11G的cardinality feedback新功能，最終得到準(zhǔn)確的基數(shù)，在10：00-10：30之間，自動糾正了執(zhí)行計劃

    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）標(biāo)紅色的為錯誤的執(zhí)行計劃及其統(tǒng)計信息

    （2）9：00—10：00之間，共發(fā)生4次錯誤的執(zhí)行計劃，其中

    （3）在前面發(fā)生4次錯誤的執(zhí)行計劃之后，由于ORACLE 11G的cardinality feedback新功能，最終得到準(zhǔn)確的基數(shù)，在9：30-10：00之間，自動糾正了執(zhí)行計劃

    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）標(biāo)紅色的為錯誤的執(zhí)行計劃及其統(tǒng)計信息

    （2）9：00—11：30之間，共發(fā)生4次錯誤的執(zhí)行計劃，其中兩次發(fā)生在9：00-9：30間

    （3）在前面發(fā)生4次錯誤的執(zhí)行計劃之后，由于ORACLE 11G的cardinality feedback新功能，最終得到準(zhǔn)確的基數(shù)，在11：00-11：30之間，自動糾正了執(zhí)行計劃

    6、引發(fā)執(zhí)行計劃錯誤原因分析

    6.1 表統(tǒng)計信息統(tǒng)計歷史

    6.1.1 LB_T_XXXJECT_PROVIDER

    序號

    用戶名

    表名

    分析歷史時間

    1

    BIDPRO

    LB_T_XXXJECT_PROVIDER

    11-8月 -13 20.06.16.630512

    2

    BIDPRO

    LB_T_XXXJECT_PROVIDER

    03-8月 -13 20.22.23.332654

    3

    BIDPRO

    LB_T_XXXJECT_PROVIDER

    26-7月 -13 22.18.08.386638

    在8月5日開標(biāo)前，該表已經(jīng)有10天未統(tǒng)計

    6.1.2 LA_XXCKAGE

    序號

    用戶名

    表名

    分析歷史時間

    1

    BIDPRO

    LA_XXCKAGE

    15-8月 -13 20.01.28.232128

    2

    BIDPRO

    LA_XXCKAGE

    09-8月 -13 20.04.35.224700

    3

    BIDPRO

    LA_XXCKAGE

    26-7月 -13 20.08.49.666682

    在8月5日開標(biāo)前，該表已經(jīng)有10天未統(tǒng)計

    6.1.3 XXCC_SUPPLIER

    序號

    用戶名

    表名

    分析歷史時間

    1

    BIDPRO

    XXCC_SUPPLIER

    18-8月 -13 20.13.21.031834

    2

    BIDPRO

    XXCC_SUPPLIER

    10-8月 -13 20.07.04.740643

    3

    BIDPRO

    XXCC_SUPPLIER

    31-7月 -13 22.00.39.107474

    4

    BIDPRO

    XXCC_SUPPLIER

    22-7月 -13 22.01.26.170018

    在8月5日開標(biāo)前，該表已經(jīng)有5天未統(tǒng)計

    6.1.4 XXCC_SUPPLIER_CONTACT

    序號

    用戶名

    表名

    分析歷史時間

    1

    BIDPRO

    XXCC_SUPPLIER_CONTACT

    17-8月 -13 20.03.30.834585

    2

    BIDPRO

    XXCC_SUPPLIER_CONTACT

    09-8月 -13 22.03.30.402420

    3

    BIDPRO

    XXCC_SUPPLIER_CONTACT

    26-7月 -13 22.07.06.696581

    在8月5日開標(biāo)前，該表已經(jīng)有10天未統(tǒng)計

    6.2 表數(shù)據(jù)變化分析

    6.2.1 8月5日前最后一次統(tǒng)計時間至8月5日時的block_changes數(shù)量

    序號

    表名

    最后一次統(tǒng)計時間

    block_changes

    1

    LB_T_XXXJECT_PROVIDER

    26-7月 -13 22.18

    158560

    2

    LA_XXCKAGE

    26-7月 -13 20.08

    168224

    3

    XXCC_SUPPLIER

    31-7月 -13 22.00

    608

    4

    XXCC_SUPPLIER_CONTACT

    26-7月 -13 22.07

    576

    6.3 錯誤執(zhí)行計劃預(yù)估數(shù)據(jù)量與真正數(shù)據(jù)量差異對比

    SQL_ID

    執(zhí)行計劃對錯區(qū)分

    對表的ROWS評估數(shù)

    XXCC_SUPPLIER_CONTACT

    XXCC_SUPPLIER

    LA_XXCKAGE

    LB_T_XXXJECT_PROVIDER

    bj75p9188y410

    錯誤執(zhí)行計劃

    30058

    1

    1

    1

    正確執(zhí)行計劃

    10M

    26139

    1

    347

    gmfktzfsd6hj3

    錯誤執(zhí)行計劃

    30058

    1

    1

    1

    正確執(zhí)行計劃

    10M

    26139

    1

    347

    1d44jc4at7xt6

    錯誤執(zhí)行計劃

    30058

    1

    1

    1

    正確執(zhí)行計劃

    10M

    26139

    1

    347

    fh86uz0ch9z9w

    錯誤執(zhí)行計劃

    30058

    1

    1

    1

    正確執(zhí)行計劃

    7763K

    26139

    1

    347

    7、解決方案建議

    建議對上述四條發(fā)生執(zhí)行計劃錯誤的SQL語句，采用SQL_PROFILE對執(zhí)行計劃進行固定，可以避免下次開標(biāo)時出現(xiàn)同樣的問題

    聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

    文檔

    數(shù)據(jù)庫服務(wù)器CPU突然持續(xù)100%后自動下降原因診斷

    數(shù)據(jù)庫服務(wù)器CPU突然持續(xù)100%后自動下降原因診斷:1、CPU接近100% nmon數(shù)據(jù) 8月5日在9：209：40之間，出現(xiàn)CPU接近100%的情況，特點表現(xiàn)為9：20左右CPU急劇攀升，在9：45左右又快速下降 2、原因分析結(jié)果總述 2.1 持續(xù)時間與恢復(fù)方式 此次CPU攀高時間持續(xù)約20分鐘，在無人工干預(yù)的情況下自動恢復(fù) 2.2 原因
    推薦度：
    標(biāo)簽： 自動 突然 原因
    • 熱門焦點

    最新推薦

    猜你喜歡

    熱門推薦

    專題
    Top
    主站蜘蛛池模板： 精品国产欧美一区二区五十路 | 日产精品久久久一区二区 | 精品国产一区二区三区成人 | 青青青国产在线观看 | 妖精视频一区二区三区 | 国产精品免费观看视频播放 | 亚洲一区免费在线观看 | 国产精品视频免费视频 | 日韩欧美亚洲 | 亚洲好骚综合 | 久久亚洲欧美综合激情一区 | 国产精品美女久久久久 | 国产一区二区三区夜色 | 明星国产欧美日韩在线观看 | 久久成人毛片 | 中文字幕日本一本二本三区 | 一区二区三区在线视频观看 | 91精品一区二区三区在线 | 热综合一本伊人久久精品 | 欧美系列在线 | 欧美一级色图 | 国产成人精品一区 | 欧美在线看欧美视频免费网站 | 自拍偷拍欧美亚洲 | 国产一区二区三区欧美 | 日韩美女一区二区三区 | 欧美最猛性xxxxx动态图 | 国产视频高清在线观看 | 欧美性俄罗斯18精品 | 午夜视频在线播放 | 亚洲精品国产成人7777 | 在线观看亚洲欧美 | 国产成人一区二区三区在线播放 | 日本国产一区二区三区 | 日本久热 | 97精品国产97久久久久久 | 国产精品色综合久久 | 国产成人精品日本亚洲语音2 | 亚洲欧美日韩在线观看播放 | 欧美一区二区日韩一区二区 | 永久免费观看的毛片的网站下载 |