執行計劃錯誤導致系統負載高
oracle: 11gr2
os : linux 5
接到監控人員報警,資料庫伺服器負載高,登陸機器查詢
select session_id,sample_id,sample_time,event,sql_id,BLOCKING_SESSION from v$active_session_history
where event is not null
and sample_time >=to_timestamp('2011-11-28 19:20:00.1','yyyy-mm-dd hh24:mi:ss.ff')
and sample_time <=to_timestamp('2011-11-28 19:50:00.1','yyyy-mm-dd hh24:mi:ss.ff') ;
SESSION_ID SAMPLE_ID SAMPLE_TIME EVENT SQL_ID BLOCKING_SESSION
---------- ---------- ------------------------------ ------------------------------ ------------- ----------------
8 2687143 28-NOV-11 07.39.31.598 PM latch: cache buffers chains 55skfxm2ufdbg
17 2687143 28-NOV-11 07.39.31.598 PM latch: cache buffers chains 55skfxm2ufdbg
18 2687143 28-NOV-11 07.39.31.598 PM latch: cache buffers chains 55skfxm2ufdbg
19 2687143 28-NOV-11 07.39.31.598 PM latch: cache buffers chains 55skfxm2ufdbg
。。。。。。。。。。。。。。。。
大量 latch: cache buffers chains 等待事件
找到對應的SQL
select sql_text from v$sqltext where sql_id='55skfxm2ufdbg' order by piece;
SQL_TEXT
----------------------------------------------------------------
SELECT DCNT, ENCNT FROM
(SELECT COUNT(*) AS DCNT FROM T_ENTERPRISE_DESTMSISDN D WHERE D.EID = :B1 AND D.DESTMSISDN = :B2 ) D,
(SELECT COUNT(*) AS ENCNT FROM T_ENTERPRISE_AMOUNT E WHERE E.EID = :B1 ) E
col column_name for a20
set lines 180
select index_name,table_name,column_name,column_position from dba_ind_columns where table_name='T_ENTERPRISE_DESTMSISDN';
INDEX_NAME TABLE_NAME COLUMN_NAME COLUMN_POSITION
------------------------------ ------------------------------ -------------------- ---------------
IND_T_ENTERPRISE_DESTMSISDN T_ENTERPRISE_DESTMSISDN EDATE 1
PK_T_ENTERPRISE_DESTMSISDN T_ENTERPRISE_DESTMSISDN EID 1
PK_T_ENTERPRISE_DESTMSISDN T_ENTERPRISE_DESTMSISDN DESTMSISDN 2
select index_name,table_name,column_name,column_position from dba_ind_columns where table_name='T_ENTERPRISE_AMOUNT';
INDEX_NAME TABLE_NAME COLUMN_NAME COLUMN_POSITION
------------------------------ ------------------------------ -------------------- ---------------
PK_T_ENTERPRISE_AMOUNT T_ENTERPRISE_AMOUNT EID 1
explain plan for
SELECT DCNT, ENCNT FROM
(SELECT COUNT(*) AS DCNT FROM T_ENTERPRISE_DESTMSISDN D WHERE D.EID = :B1 AND D.DESTMSISDN = :B2 ) D,
(SELECT COUNT(*) AS ENCNT FROM T_ENTERPRISE_AMOUNT E WHERE E.EID = :B1 ) E;
select * from table(dbms_xplan.display);
------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 26 | 3 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 1 | 26 | 3 (0)| 00:00:01 |
| 2 | VIEW | | 1 | 13 | 2 (0)| 00:00:01 |
| 3 | SORT AGGREGATE | | 1 | 16 | | |
|* 4 | INDEX FAST FULL SCAN| PK_T_ENTERPRISE_DESTMSISDN | 1 | 16 | 2 (0)| 00:00:01 |
| 5 | VIEW | | 1 | 13 | 1 (0)| 00:00:01 |
| 6 | SORT AGGREGATE | | 1 | 4 | | |
|* 7 | INDEX UNIQUE SCAN | PK_T_ENTERPRISE_AMOUNT | 1 | 4 | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - filter("D"."EID"=1234 AND "D"."DESTMSISDN"='23434')
7 - access("E"."EID"=1234)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
98876 consistent gets
0 physical reads
0 redo size
590 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
T_ENTERPRISE_DESTMSISDN 表索引全掃描,EID 和 DESTMSISDN 為主鍵,應該是INDEX UNIQUE SCAN才對,肯定是執行計劃出了問題,導致邏輯讀高
採用如下 解決方法:
1. exec dbms_statS.GATHER_TABLE_STATS('USER_NESHUOKE','T_ENTERPRISE_DESTMSISDN');
2. 新增暗示 /*+ no_index_ffs */
SELECT DCNT, ENCNT FROM
(SELECT /*+ no_index_ffs */ COUNT(*) AS DCNT FROM user_neshuoke.T_ENTERPRISE_DESTMSISDN D WHERE D.EID = :B1 AND D.DESTMSISDN = :B2 ) D,
(SELECT COUNT(*) AS ENCNT FROM user_neshuoke.T_ENTERPRISE_AMOUNT E WHERE E.EID = :B1 ) E;
3. 表使用空間浪費嚴重,必要的時候進行move 表和rebuild 索引操作
最佳化後:
Execution Plan
----------------------------------------------------------
Plan hash value: 3996183545
---------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 26 | 3 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 1 | 26 | 3 (0)| 00:00:01 |
| 2 | VIEW | | 1 | 13 | 2 (0)| 00:00:01 |
| 3 | SORT AGGREGATE | | 1 | 16 | | |
|* 4 | INDEX UNIQUE SCAN| PK_T_ENTERPRISE_DESTMSISDN | 1 | 16 | 2 (0)| 00:00:01 |
| 5 | VIEW | | 1 | 13 | 1 (0)| 00:00:01 |
| 6 | SORT AGGREGATE | | 1 | 4 | | |
|* 7 | INDEX UNIQUE SCAN| PK_T_ENTERPRISE_AMOUNT | 1 | 4 | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("D"."EID"=1234 AND "D"."DESTMSISDN"='23434')
7 - access("E"."EID"=1234)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
590 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
執行計劃正常。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/21601207/viewspace-712268/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 執行計劃變化導致CPU負載高的問題分析負載
- 統計資訊不正確導致執行計劃的錯誤選擇
- autotrace 和explain plan for可能導致執行計劃錯誤AI
- 11G的SORT GROUP BY NOSORT導致錯誤執行計劃
- RLM$SCHDNEGACTION 執行導致負載問題負載
- Oracle備份時系統負載過高導致ORA-3136錯誤和AIX系統的3D32B80D錯誤Oracle負載AI3D
- Grant許可權導致執行計劃失效
- 統計資訊不準確導致執行計劃走了笛卡爾積
- 交流(1)-- 執行計劃錯誤問題
- 索引失效系列——統計量過期引起執行計劃錯誤索引
- 完美的執行計劃導致的效能問題
- 執行計劃的偏差導致的效能問題
- PHP-FPM 導致負載過高的排查方法 善用PHP慢執行日誌slow logPHP負載
- MySQL5.6執行計劃錯誤案例分析MySql
- 動態建立 @ViewChild 導致執行時錯誤的原因分析View
- 由於統計量失真造成SQL執行計劃錯誤一例SQL
- Oracle當number型別超過一定長度直方圖限制導致SQL執行計劃錯誤Oracle型別直方圖SQL
- _optimizer_invalidation_periond導致收集統計資訊後執行計劃沒有改變
- date列統計資訊陳舊導致sql沒有選擇最優執行計劃SQL
- 低效sql導致DB負載很高SQL負載
- 慎用sys_context,可能導致無法正確的bind_peeking,而選擇錯誤的執行計劃Context
- /etc/fstab的錯誤設定導致系統啟動失敗
- ORACLE analyse table方式收集表統計資訊導致SQL執行計劃不準確而效能下降OracleSQL
- 故障分析 | 大量短時程式導致 cpu 負載過高案例一則負載
- MySQL 因資料型別轉換導致執行計劃使用低效索引MySql資料型別索引
- 執行計劃中的COLLECTION ITERATOR PICKLER FETCH導致的效能問題
- 檢視執行計劃出現ORA-22992錯誤
- 統計資訊過舊導致SQL無法執行出來SQL
- 多餘索引導致explain錯誤索引AI
- 使用錯誤的作業系統使用者exp資料導致ORA-15186錯誤作業系統
- 系統日期設定不正確導致的ORA-01839錯誤
- 一次ORACLE SQL謂詞跨界導致的執行計劃不準OracleSQL
- 執行計劃問題導致處理速度時快時慢的問題
- 【PG執行計劃】Postgresql資料庫執行計劃統計資訊簡述SQL資料庫
- MES製造執行系統生產計劃管理
- 執行計劃-1:獲取執行計劃
- impdp時parallel=4導致的錯誤Parallel
- Node出錯導致執行崩潰的解決方案