點擊下載
本文文檔

當前位置：首頁 - 科技 - 知識百科 - 正文

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

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

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

數(shù)據(jù)庫服務器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ù)時間與恢復方式此次CPU攀高時間持續(xù)約20分鐘，在無人工干預的情況下自動恢復 2.2 原因

推薦度：

點擊下載本文 文檔為doc格式

導讀數(shù)據(jù)庫服務器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ù)時間與恢復方式此次CPU攀高時間持續(xù)約20分鐘，在無人工干預的情況下自動恢復 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ù)時間與恢復方式此次CPU攀高時間持續(xù)約20分鐘，在無人工干預的情況下自動恢復 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ù)時間與恢復方式

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

2.2 原因分析總述：

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

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

此處為選擇一條最嚴重的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資源消耗差異巨大對比

此處為選擇一條最嚴重的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 問題自動修復原因

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

cardinality feedback used for this statement

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

此在列出時間與AWR快照對應信息的原因為后續(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）上述標紅色語句共四條，其中第4條和第10條其實為同一條SQL語句

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

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

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

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

（6）上述標紅色語句都是在幾次錯誤選擇后有效的利用了ORACLE11g的新特性cardinalityfeedback功能，最終得到準確的基數(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）標紅色的為錯誤的執(zhí)行計劃及其統(tǒng)計信息

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

（3）在前面發(fā)生9次錯誤的執(zhí)行計劃之后，由于ORACLE 11G的cardinality feedback新功能，最終得到準確的基數(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）標紅色的為錯誤的執(zhí)行計劃及其統(tǒng)計信息

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

（3）在前面發(fā)生6次錯誤的執(zhí)行計劃之后，由于ORACLE 11G的cardinality feedback新功能，最終得到準確的基數(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）標紅色的為錯誤的執(zhí)行計劃及其統(tǒng)計信息

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

（3）在前面發(fā)生4次錯誤的執(zhí)行計劃之后，由于ORACLE 11G的cardinality feedback新功能，最終得到準確的基數(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）標紅色的為錯誤的執(zhí)行計劃及其統(tǒng)計信息

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

（3）在前面發(fā)生4次錯誤的執(zhí)行計劃之后，由于ORACLE 11G的cardinality feedback新功能，最終得到準確的基數(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日開標前，該表已經(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日開標前，該表已經(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日開標前，該表已經(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日開標前，該表已經(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í)行計劃預估數(shù)據(jù)量與真正數(shù)據(jù)量差異對比

SQL_ID	執(zhí)行計劃對錯區(qū)分	對表的ROWS評估數(shù)
SQL_ID	執(zhí)行計劃對錯區(qū)分	XXCC_SUPPLIER_CONTACT	XXCC_SUPPLIER	LA_XXCKAGE	LB_T_XXXJECT_PROVIDER
bj75p9188y410	錯誤執(zhí)行計劃	30058	1	1	1
bj75p9188y410	正確執(zhí)行計劃	10M	26139	1	347
gmfktzfsd6hj3	錯誤執(zhí)行計劃	30058	1	1	1
gmfktzfsd6hj3	正確執(zhí)行計劃	10M	26139	1	347
1d44jc4at7xt6	錯誤執(zhí)行計劃	30058	1	1	1
1d44jc4at7xt6	正確執(zhí)行計劃	10M	26139	1	347
fh86uz0ch9z9w	錯誤執(zhí)行計劃	30058	1	1	1
fh86uz0ch9z9w	正確執(zhí)行計劃	7763K	26139	1	347

7、解決方案建議

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

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

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

推薦度：

點擊下載本文 文檔為doc格式

標簽：自動突然原因

熱門焦點

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

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

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

最新推薦

猜你喜歡

熱門推薦