1、oracle 幾個重要的關聯技術執行計劃 優化器 Hints analyze dbms_stats explain plan Oracle對數據的訪問方式 今天特別回顧了一下這幾個非常非常重要的技術。(oralce太深了)SQL> ?/rdbms/admin/utlxplan.sql #創建 plan_table; 表SQL> explain plan for select count(*) from scott.temp01;Explained.完成explain plan之后，會把分析結果寫入plan_table表中2 SQL跟蹤文件，參數timed_statistics ,m

2、ax_dump_file_size, user_dump_des 三個參數分別設計時間，大小，以及路徑。設計sql_trace 參數開啟3 設計set autotrace on set timing on命令 SQL> select count(*) from scott.emp;COUNT(*)-14Execution Plan-Plan hash value: 2937609675-| Id | Operation | Name | Rows | Cost (%CPU)| Time |-| 0 | SELECT STATEMENT | | 1 | 1 (0)| 00:00:01 |

3、1 | SORT AGGREGATE | | 1 | | | 2 | INDEX FULL SCAN| PK_EMP | 14 | 1 (0)| 00:00:01#在這里會發現，此處提到一個關于對表的訪問方式 全表掃描 索引掃描（也就是rowid）可以使用hint來強制3 第三種就是使用pl/sql了，這部就不說明了二 優化器 oracle的優化器有CBO與RBO兩種，用參數 optimizer_mode 優化模式設定，共有Rule,Choose,First rows,All rows這四種方式-Rule Based Optimizer（RBO）基于規則Cost Based Optimizer

4、（CBO）基于成本，或者講統計信息ORACLE 提供了CBO、RBO兩種SQL優化器。CBO在ORACLE7 引入，但在ORACLE8i 中才成熟。ORACLE 已經明確聲明在ORACLE9i之后的版本中(ORACLE 10G )，RBO將不再支持。因此選擇CBO 是必然的趨勢。CBO和 RBO作為不同的SQL優化器，對SQL語句的執行計劃產生重大影響，如果要對現有的應用程序從RBO向CBO移植，則必須充分考慮這些影響，避免SQL 語句性能急劇下降；但是，對新的應用系統，則可以考慮直接使用CBO，在CBO模式下進行SQL語句編寫、分析執行計劃、性能測試等工作，這需要開發者對 CBO的特性比較熟

5、悉。以下小結幾點在CBO下寫SQL語句的注意事項：1、RBO自ORACLE 6版以來被采用，有著一套嚴格的使用規則，只要你按照它去寫SQL語句，無論數據表中的內容怎樣，也不會影響到你的“執行計劃”，也就是說對數據不“敏 感”；CBO計算各種可能“執行計劃”的“代價”，即cost，從中選用cost最低的方案，作為實際運行方案。各“執行計劃”的cost的計算根據，依 賴于數據表中數據的統計分布，ORACLE數據庫本身對該統計分布并不清楚，必須要分析表和相關的索引（使用ANALYZE 命令），才能搜集到CBO所需的數據。2、使用CBO 時，編寫SQL語句時，不必考慮"FROM"

6、子句后面的表或視圖的順序和"WHERE" 子句后面的條件順序；ORACLE自7版以來采用的許多新技術都是基于CBO的，如星型連接排列查詢，哈希連接查詢，函數索引，和并行查詢等。3、一般而言，CBO所選擇的“執行計劃”都不會比RBO的“執行計劃”差，而且相對而言，CBO對程序員的要求沒有RBO那么苛刻，節省了程序員 為了從多個可能的“執行計劃”中選擇一個最優的方案而花費的調試時間，但在某些場合下也會存在問題。較典型的問題有：有時，表明明建有索引，但查詢過程顯 然沒有用到相關的索引，導致查詢過程耗時漫長，占用資源巨大，這時就需要仔細分析執行計劃，找出原因。例如，可以看連接順序是

7、否允許使用相關索引。假設表 emp的deptno列上有索引，表dept的列deptno上無索引，WHERE語句有emp.deptno=dept.deptno條件。在做NL連 接時，emp做為外表，先被訪問，由于連接機制原因，外表的數據訪問方式是全表掃描，emp.deptno上的索引顯然是用不上，最多在其上做索引全掃描 或索引快速全掃描。4、如果一個語句使用 RBO的執行計劃確實比CBO 好，則可以通過加 " rule" 提示，強制使用RBO。5、使用CBO 時，SQL語句 "FROM" 子句后面的表，必須全部使用ANALYZE 命令分析過，如果"

8、;FROM" 子句后面的是視圖，則此視圖的基礎表，也必須全部使用ANALYZE 命令分析過；否則，ORACLE 會在執行此SQL語句之前，自動進行ANALYZE 命令分析，這會極大導致SQL語句執行極其緩慢。6、使用CBO 時，SQL語句 "FROM" 子句后面的表的個數不宜太多，因為CBO在選擇表連接順序時，會對"FROM" 子句后面的表進行階乘運算，選擇最好的一個連接順序。假如"FROM" 子句后有6個表，則其可選擇的連接順序就是6*5*4*3*2*1 = 720 種，CBO 選擇其中一種，而如果"FROM&q

9、uot; 子句后有12個表，則其可選擇的連接順序就是12*11*10*9*8*7*6*5*4*3*2*1= 479001600 種，可以想象從中選擇一種，會消耗多少CPU 時間？如果實在是要訪問很多表，則最好使用 ORDER 提示，強制使用"FROM" 子句表固定的訪問順序。7、使用CBO 時，SQL語句中不能引用系統數據字典表或視圖，因為系統數據字典表都未被分析過，可能導致極差的“執行計劃”。但是不要擅自對數據字典表做分析，否則可 能導致死鎖，或系統性能嚴重下降。8、使用CBO 時，要注意看采用了哪種類型的表連接方式。ORACLE的共有Sort Merge Join（SM

10、J）、Hash Join（HJ）和Nested Loop Join（NL）。CBO有時會偏重于SMJ 和 HJ，但在OLTP 系統中，NL 一般會更好，因為它高效的使用了索引。在兩張表連接，且內表的目標列上建有索引時，只有Nested Loop才能有效地利用到該索引。SMJ即使相關列上建有索引，最多只能因索引的存在，避免數據排序過程。HJ由于須做HASH運算，索引的存在對數據查 詢速度幾乎沒有影響。9、使用CBO 時，必須保證為表和相關的索引搜集足夠的統計數據。對數據經常有增、刪、改的表最好定期對表和索引進行分析，可用SQL語句“analyze table xxx compute statis

11、tics for all indexes;"ORACLE掌握了充分反映實際的統計數據，才有可能做出正確的選擇。10、使用CBO 時，要注意被索引的字段的值的數據分布，會影響SQL語句的執行計劃。例如：表emp，共有一百萬行數據，但其中的emp.deptno列，數據只有4種 不同的值，如10、20、30、40。雖然emp數據行有很多，ORACLE缺省認定表中列的值是在所有數據行均勻分布的，也就是說每種deptno值各 有25萬數據行與之對應。假設SQL搜索條件DEPTNO=10，利用deptno列上的索引進行數據搜索效率，往往不比全表掃描的高，ORACLE理所 當然對索引“視而不見”，認為該索引的選擇性不高。我們考慮另一種情況，如果一百萬數據行實際不是在4種deptno值間平均分配，其中