2. 程式人生 > >使用hint優化Oracle的運行計劃 以及 SQL Tune Advisor的使用

使用hint優化Oracle的運行計劃 以及 SQL Tune Advisor的使用

阿新 • • 發佈：2019-04-21
dual sss 嚴重 acl lang put rec fix values

背景：

某表忽然出現查詢很緩慢的情況。cost 100+ 秒以上；嚴重影響生產。


原SQL：

explain plan for 
select * from (
select ID id,RET_NO retNo, FROM_SYS fromSy, TO_SYS toSys, COMMAND_CODE commandCode, COMMAND, STATUS, 
EXT_CODE, ORIGN_CODE orignCode,error_message errorMessage, RE_F, RET_MSG retMsg 
from interface_table where ((command_code in(‘AASSS‘) 
			and  status in(‘F‘,‘E‘) and (re_f = ‘N‘) and FROM_SYS = ‘MEE‘)
			or (COMMAND_CODE in(‘XXXX‘,‘XXXX9‘) and FROM_SYS = ‘EXT‘ and RE_F = ‘N‘)
			) and MOD(id, 1) = 0  order by id) where rownum <= 100  ;
查看其運行計劃：
SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY(‘PLAN_TABLE‘));
Plan hash value: 1871549687
?
----------------------------------------------------------------------------------------------------
| Id? | Operation???????????????????? | Name?????????????? | Rows? | Bytes | Cost (%CPU)| Time???? |
----------------------------------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT????????????? |??????????????????? |??? 99 |?? 382K|?? 637?? (1)| 00:00:08 |
|*? 1 |? COUNT STOPKEY??????????????? |??????????????????? |?????? |?????? |??????????? |????????? |
|?? 2 |?? VIEW??????????????????????? |??????????????????? |?? 100 |?? 386K|?? 637?? (1)| 00:00:08 |
|*? 3 |??? TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE??? |?? 355 | 55735 |?? 637?? (1)| 00:00:08 |
|*? 4 |???? INDEX FULL SCAN?????????? | PK_INTERFACE_TABLE |? 1439 |?????? |?? 280?? (2)| 00:00:04 |
----------------------------------------------------------------------------------------------------


優化後的SQL：

explain plan for 
select * from (
select /*+ index(INT_TABLE IX_INT_TABLE_2)*/ ID id,RET_NO retNo, FROM_SYS fromSy, TO_SYS toSys, COMMAND_CODE commandCode, COMMAND, STATUS, 
EXT_CODE, ORIGN_CODE orignCode,error_message errorMessage, RE_F, RET_MSG retMsg 
from interface_table where ((command_code in(‘AASSS‘) 
			and  status in(‘F‘,‘E‘) and (re_f = ‘N‘) and FROM_SYS = ‘MEE‘)
			or (COMMAND_CODE in(‘XXXX‘,‘XXXX9‘) and FROM_SYS = ‘EXT‘ and RE_F = ‘N‘)
			) and MOD(id, 1) = 0 order by id) where rownum <= 100  ;
查看其運行計劃： 

SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY(‘PLAN_TABLE‘));
Plan hash value: 3625182869
?
--------------------------------------------------------------------------------------------------------
| Id? | Operation?????????????????????? | Name???????????????? | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT??????????????? |????????????????????? |??? 99 |?? 382K| 19105?? (1)| 00:03:50 |
|*? 1 |? COUNT STOPKEY????????????????? |????????????????????? |?????? |?????? |??????????? |????????? |
|?? 2 |?? VIEW????????????????????????? |????????????????????? |?? 356 |? 1376K| 19105?? (1)| 00:03:50 |
|*? 3 |??? SORT ORDER BY STOPKEY??????? |????????????????????? |?? 356 | 55892 | 19105?? (1)| 00:03:50 |
|?? 4 |???? CONCATENATION?????????????? |????????????????????? |?????? |?????? |??????????? |????????? |
|*? 5 |????? TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE????? |??? 69 | 10833 |? 9552?? (1)| 00:01:55 |
|*? 6 |?????? INDEX RANGE SCAN????????? | IX_INTERFACE_TABLE_2 | 77145 |?????? |??? 99?? (0)| 00:00:02 |
|*? 7 |????? TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE????? |?? 287 | 45059 |? 9552?? (1)| 00:01:55 |
|*? 8 |?????? INDEX RANGE SCAN????????? | IX_INTERFACE_TABLE_2 | 77145 |?????? |??? 99?? (0)| 00:00:02 |
--------------------------------------------------------------------------------------------------------


比較：

查看運行計劃。原來是使用 full scan - 當數據量大時很慢。優化後oracle優先走range scan，hint 的 index 是未處理標識字段的索引，正常情況下這個數據集合相對較小--------所以能夠達到優化目的。

詳細情況詳細分析，我們必需要看實際的表存的業務數據。分析其業務關系找到最小業務集合。後者要看懂運行計劃，依據rows, bytes, cost, time 找到最優項目。這個分析順序不能倒置。

問題：為何使用 rownum 後，oracle運行計劃會走full scan？


轉：怎樣看懂運行計劃：http://jadethao.iteye.com/blog/1613943


====? section2 ====

http://blog.chinaunix.net/uid-77311-id-3233190.html

環境: OS:Red Hat Linux As 5 DB:10.2.0.4 ? Oracle通過STA給出某個SQL運行建議,以下通過一個測試檢查Oracle給出的優化建議是否正確. ? 1.建表並生成測試數據 SQL> create table tb_test(id number not null,name varchar2(30)); Table created. SQL> create index idx_tb_test on tb_test(id); Index created. SQL> declare
begin
? for i in 1 .. 100000 loop
??? insert into tb_test values (i, ‘test‘);
??? commit;
? end loop;
end;
/ ? 2.分析表 begin
? dbms_stats.gather_table_stats(ownname => ‘SCOTT‘, tabname => ‘TB_TEST‘);
end;

3.編造一個運行計劃不正確的SQL

select/*+ full(t)*/ count(1) from scott.tb_test t where t.id=1

我們知道在ID列上有索引,這個SQL走索引是正確的運行計劃,但這裏強制oracle走全表掃描,然後通過STA,看oracle給出的運行計劃是否正確.

4.創建TUNING_TASK並運行

declare
? l_task_name varchar2(30);
? l_sql?????? clob;
begin
? l_sql?????? := ‘select/*+ full(t)*/ count(1) from scott.tb_test t where t.id=1‘;
? l_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_text??? => l_sql,
???????????????????????????????????????????????? user_name?? => ‘SCOTT‘,
???????????????????????????????????????????????? scope?????? => ‘COMPREHENSIVE‘,
???????????????????????????????????????????????? time_limit? => 60,
???????????????????????????????????????????????? task_name?? => ‘task_name01‘,
???????????????????????????????????????????????? description => null);
dbms_sqltune.Execute_tuning_task(task_name => ‘task_name01‘);
end;

5.查看oracle給出的優化建議

SQL> set serveroutput on;
SQL> set long 999999999;
SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK(‘task_name01‘) FROM DUAL;

DBMS_SQLTUNE.REPORT_TUNING_TASK(‘TASK_NAME01‘)
--------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name????????????????? : task_name01
Tuning Task Owner???????????????? : SYS
Scope???????????????????????????? : COMPREHENSIVE
Time Limit(seconds)?????????????? : 60
Completion Status???????????????? : COMPLETED
Started at??????????????????????? : 06/03/2012 00:07:58
Completed at????????????????????? : 06/03/2012 00:07:59
Number of SQL Profile Findings??? : 1


DBMS_SQLTUNE.REPORT_TUNING_TASK(‘MY_TASK_NAME01‘)
--------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Schema Name: SCOTT
SQL ID???? : ga3q5tqjgsj5u
SQL Text?? : select/*+ full(t)*/ count(1) from scott.tb_test t where t.id=1

-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------

1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------

DBMS_SQLTUNE.REPORT_TUNING_TASK(‘MY_TASK_NAME01‘)
--------------------------------------------------------------------------------
? A potentially better execution plan was found for this statement.

? Recommendation (estimated benefit: 84.11%)
? ------------------------------------------
? - Consider accepting the recommended SQL profile.
??? execute dbms_sqltune.accept_sql_profile(task_name => ‘task_name01‘,
??????????? replace => TRUE);

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

DBMS_SQLTUNE.REPORT_TUNING_TASK(‘TASK_NAME01‘)
--------------------------------------------------------------------------------

1- Original With Adjusted Cost
------------------------------
Plan hash value: 1372292586

--------------------------------------------------------------------------------

| Id? | Operation????????? | Name????? | Rows? | Bytes | Cost (%CPU)| Time???? |

--------------------------------------------------------------------------------

-- 當前的運行計劃
DBMS_SQLTUNE.REPORT_TUNING_TASK(‘TASK_NAME01‘)
--------------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT?? |?????????? |???? 1 |???? 4 |???? 6?? (0)| 00:00:01 |

|?? 1 |? SORT AGGREGATE??? |?????????? |???? 1 |???? 4 |??????????? |????????? |

|*? 2 |?? TABLE ACCESS FULL| TB_TEST? ?|???? 1 |???? 4 |???? 6?? (0)| 00:00:01 |

--------------------------------------------------------------------------------


Predicate Information (identified by operation id):
---------------------------------------------------

DBMS_SQLTUNE.REPORT_TUNING_TASK(‘TASK_NAME01‘)
--------------------------------------------------------------------------------

?? 2 - filter("T"."ID"=1)

?

-- Oracle給出的運行計劃

2- Using SQL Profile
--------------------
Plan hash value: 847665939

--------------------------------------------------------------------------------
---
| Id? | Operation???????? | Name????????? | Rows? | Bytes | Cost (%CPU)| Time
? |

DBMS_SQLTUNE.REPORT_TUNING_TASK(‘TASK_NAME01‘)
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
---
|?? 0 | SELECT STATEMENT? |?????????????? |???? 1 |???? 4 |???? 1?? (0)| 00:00:0
1 |
|?? 1 |? SORT AGGREGATE?? |?????????????? |???? 1 |???? 4 |??????????? |
? |
|*? 2 |?? INDEX RANGE SCAN| IDX_TB_TEST? ?|???? 1 |???? 4 |???? 1?? (0)| 00:00:0
1 |
--------------------------------------------------------------------------------
---


DBMS_SQLTUNE.REPORT_TUNING_TASK(‘TASK_NAME01‘)
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

?? 2 - access("T"."ID"=1)

-------------------------------------------------------------------------------

從上面的輸出能夠看出Oracle給出的運行計劃是正確的.能夠使用例如以下方法使用正確的運行計劃

begin
? dbms_sqltune.accept_sql_profile(task_name => ‘task_name01‘, replace => TRUE);
end;

-- The End --




使用hint優化Oracle的運行計劃 以及 SQL Tune Advisor的使用

相關推薦

使用hint優化Oracle的執行計劃 以及 SQL Tune Advisor的使用

背景： 某表忽然出現查詢非常緩慢的情況，cost 100+ 秒以上；嚴重影響生產。 原SQL： explain plan for select * from ( select ID id,RET_NO retNo, FROM_SYS fromSy, TO_SYS to

使用hint優化Oracle的運行計劃 以及 SQL Tune Advisor的使用

dual sss 嚴重 acl lang put rec fix values 背景： 某表忽然出現查詢很緩慢的情況。cost 100+ 秒以上；嚴重影響生產。

SQL Server 運行計劃操作符具體解釋（2）——串聯(Concatenation )

-s 而且 article font order close 格式 聚集索引 content 本文接上文：SQL Server 運行計劃操作符具體解釋（1）——斷言(Assert)前言： 依據計劃。本文開始講述另外一個操作符串聯（Concatenation）。讀者能夠依

閃回drop恢復表後sql運行計劃異常

for 恢復 per style lec name ora acl ont -----正常運行計劃 set autotrace traceonly set linesize 1000 select /*+index(t idx_object

[Oracle] 獲取運行計劃的各方法總結

mit statistic 另一個 waiting 長時間 trac process one ext 總的結論： 一.獲取運行計劃的6種方法(具體步驟已經在每一個樣例的開頭凝視部分說明了）： 1. explain plan for獲取； 2. set aut

使用hint優化 Oracle SQL語句方法30例

在SQL語句優化過程中，我們經常會用到hint,現總結一下在SQL優化過程中常見Oracle HINT的用法：1. /*+ALL_ROWS*/表明對語句塊選擇基於開銷的優化方法,並獲得最佳吞吐量,使資源消耗最小化.例如:SELECT /*+ALL+_ROWS*/ EMP_NO,EMP_NAM,DAT_IN F

關於算法運行時間以及“管道”為什麽引入

cin blog for sed 常數 scanf 結果 運行時 pre 1. 關於算法運行時間以及“管道”為什麽引入。 我以前畢設比較不同譯碼算法的時候，直接用一個clock（）來比較不同算法運行速率。現在想起來，這是及其錯誤了！ 《算法競賽入門經典》P64 一個

Sublime Text 3運行程序以及分欄快捷鍵的設置

紅色 tools 兩個 -- conf fig run 快捷鍵 分欄 Sublime Text 3軟件由於每次運行程序都要執行：Tools -> SublimeREPL -> Python -> RUN current file 菜單有點麻煩，所以現在可以

運行時報java.sql.SQLException: No suitable driver的幾種解決辦法

服務 .sql onf lex except pan java_home root ext 原因：（1）很有可能c3p0-config.xml中的配置文件出現問題，比如我是因為把“driverClass”不小心寫成了“driver”，

運行.bat執行sql文件 —— mysql

log host fault rds rec color done 四川 htm 參考地址：https://www.cnblogs.com/dingjiaoyang/p/9990188.html 運行test.bat 執行 test.sql文件 test.bat： @

面向 Unity* 軟件和虛擬現實的優化：運行時生成內容

實的 我們 嘗試 tel zh-cn 介紹 虛擬 面向 content 優化遊戲以實現高性能一直是遊戲開發過程中的一個重要因素。雖然開發人員一直嘗試將硬件推向極致，但當移動遊戲成為主流時，優化技術變得尤為突出。Unity* 軟件、Unreal* 等常見引擎最初都是面向 PC

db2 優化基礎 查詢運行時間最長的SQL

使用 family pool pan select d+ 運行時間 dynamics sin 之前寫過一個查詢運行查看運行時間最長的應用。查詢到的是，應用程序。比如我的程序。查到的是IIS，沒什麽用。select elapsed_time_min,appl_status,

oracle資料庫建立索引以及簡單優化sql語句

Oracle 建立索引及SQL優化 資料庫索引: 索引有單列索引 複合索引之說 如何某表的某個欄位有主鍵約束和唯一性約束，則Oracle 則會自動在相應的約束列上建議唯一索引。資料庫索引主要進行提高訪問速度。 建設原則: 　1、索引應該經常建在Where 子句經常用到的列上。如

SQL Server 執行計劃利用統計資訊對資料行的預估原理以及SQL Server 2014中預估策略的改變

前提 　 　　  本文僅討論SQL Server查詢時，　　　　對於非複合統計資訊，也即每個欄位的統計資訊只包含當前列的資料分佈的情況下，　　　　在用多個欄位進行組合查詢的時候，如何根據統計資訊去預估行數的。　　　　利用不同欄位的統計資訊做資料行數預估的演算法原理，以及SQL Server 2012和S

SQL Server調優系列玩轉篇（如何利用查詢提示（Hint）引導語句運行）

dash 得到 概念理解 一點 html 維護 導致 最好 生態環境 前言 前面幾篇我們分析了關於SQL Server關於性能調優的一系列內容，我把它分為兩個模塊。 第一個模塊註重基礎內容的掌握，共分7篇文章完成，內容涵蓋一系列基礎運算算法，詳細分析了如何查看執行計劃、

[Django] 查看orm自己主動運行的原始查詢sql

ice 微軟 bug sof execute 通過 nec cut ren django的文檔看了非常多。也用了不少，有的時候感覺性能非常不好，知道非常多地方是惰性查詢。可是對於復雜的邏輯。僅僅是表面上發現執行非常慢，機器資源消耗非常多。卻不知道orm究竟是什麽來轉化成

ASP.NET MVC 提高運行速度的幾種性能優化方法

服務 排隊 等待 谷歌搜索 部署 lan str run 提高 主要介紹ASP.NETMVC 應用提速的六種方法，因為沒有人喜歡等待，所以介紹幾種常用的優化方法。 大家可能會遇到排隊等待，遇到紅燈要等待，開個網頁要等待，等等等。 理所當然，沒有人喜歡等待網頁慢吞吞地加載

基於sparksql調用shell腳本運行SQL

cor when ota round columns cat 基於 exec url [Author]: kwu 基於sparksql調用shell腳本運行SQL，sparksql提供了類似hive中的 -e , -f ,-i的選項 1、定時調用腳本 #!/b

sql優化（oracle）- 第二部分 常用sql用法和註意事項

個數 its 用法 記錄 減少 合並 .com 語句 一個 第二部分 常用sql用法和註意事項 1. exists 和 in 2. union 和 union all

開啟Tomcat APR運行模式，優化並發性能

jdk title library err 添加 open io模式 1.4 -1 Tomcat支持三種接收請求的處理方式：BIO、NIO、APR 1>、BIO模式：阻塞式I/O操作，表示Tomcat使用的是傳統Java I/O操作(即Java.io包及其子包)。To