oracle優化器的rbo和cbo方式
oracle 提供了cbo、rbo兩種sql優化器。cbo在oracle7 引入，但在oracle8i 中才成熟。oracle 已經明確宣告在oracle9i之後的版本中(oracle 10g )，rbo將不再支援。因此選擇cbo 是必然的趨勢。 www.2cto.com
cbo和 rbo作為不同的sql優化器，對sql語句的執行計畫產生重大影響，如果要對現有的應用程式從rbo向cbo移植，則必須充分考慮這些影響，避免sql語句效能急劇下降；但是，對新的應用系統，則可以考慮直接使用cbo，在cbo模式下進行sql語句編寫、分析執行計畫、效能測試等工作，這需要開發者對cbo的特性比較熟悉。以下小結幾點在cbo下寫sql語句的注意事項：
1、rbo自oracle 6版以來被採用，有著一套嚴格的使用規則，只要你按照它去寫sql語句，無論資料表中的內容怎樣，也不會影響到你的「執行計畫」，也就是說對資料不「敏感」；cbo計算各種可能「執行計畫」的「代價」，即cost，從中選用cost最低的方案，作為實際執行方案。各「執行計畫」的cost的計算根據，依賴於資料表中資料的統計分布，oracle資料庫本身對該統計分布並不清楚，必須要分析表和相關的索引（使用analyze 命令），才能蒐集到cbo所需的資料。
2、使用cbo 時，編寫sql語句時，不必考慮"from" 子句後面的表或檢視的順序和"where" 子句後面的條件順序；
oracle自7版以來採用的許多新技術都是基於cbo的，如星型連線排列查詢，雜湊連線查詢，函式索引，和並行查詢等。
3、一般而言，cbo所選擇的「執行計畫」都不會比rbo的「執行計畫」差，而且相對而言，cbo對程式設計師的要求沒有rbo那麼苛刻，節省了程式設計師為了從多個可能的「執行計畫」中選擇乙個最優的方案而花費的除錯時間，但在某些場合下也會存在問題。
較典型的問題有：有時，表明明建有索引，但查詢過程顯然沒有用到相關的索引，導致查詢過程耗時漫長，占用資源巨大，這時就需要仔細分析執行計畫，找出原因。例如，可以看連線順序是否允許使用相關索引。假設表emp的deptno列上有索引，表dept的列deptno上無索引，where語句有emp.deptno=dept.deptno條件。在做nl連線時，emp做為外表，先被訪問，由於連線機制原因，外表的資料訪問方式是全表掃瞄，emp.deptno上的索引顯然是用不上，最多在其上做索引全掃瞄或索引快速全掃瞄。 www.2cto.com
4、如果乙個語句使用 rbo的執行計畫確實比cbo 好，則可以通過加 " rule" 提示，強制使用rbo。
5、使用cbo 時，sql語句 "from" 子句後面的表，必須全部使用analyze 命令分析過，如果"from" 子句後面的是檢視，則此檢視的基礎表，也必須全部使用analyze 命令分析過；否則，oracle 會在執行此sql語句之前，自動進行analyze 命令分析，這會極大導致sql語句執行極其緩慢。
6、使用cbo 時，sql語句 "from" 子句後面的表的個數不宜太多，因為cbo在選擇表連線順序時，會對"from" 子句後面的表進行階乘運算，選擇最好的乙個連線順序。假如"from" 子句後有6個表，則其可選擇的連線順序就是6*5*4*3*2*1 = 720 種，cbo 選擇其中一種，而如果"from" 子句後有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（smj）、hash join（hj）和nested loop join（nl）。cbo有時會偏重於smj 和 hj，但在oltp 系統中，nl 一般會更好，因為它高效的使用了索引。在兩張表連線，且內錶的目標列上建有索引時，只有nested loop才能有效地利用到該索引。smj即使相關列上建有索引，最多只能因索引的存在，避免資料排序過程。hj由於須做hash運算，索引的存在對資料查詢速度幾乎沒有影響。
9、使用cbo 時，必須保證為表和相關的索引蒐集足夠的統計資料。對資料經常有增、刪、改的表最好定期對錶和索引進行分析，可用sql語句「analyze table *** compute statistics 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值間平均分配，其中有99萬行對應著值10，5000行對應值20，3000行對應值30，2000行對應值40。在這種資料分布圖案中對除值為10外的其它deptno值搜尋時，毫無疑問，如果索引能被應用，那麼效率會高出很多。我們可以採用對該索引列進行單獨分析，或用analyze語句對該列建立直方圖，對該列蒐集足夠的統計資料，使oracle在搜尋選擇性較高的值能用上索引。
Oracle的優化器的RBO和CBO方式
1 基於規則的優化方式 rule based optimization，簡稱為rbo 優化器在分析sql語句時,所遵循的是oracle內部預定的一些規則，對資料是不敏感的。它只借助少量的資訊來決定乙個sql語句的執行計畫，包括 1 sql語句本身 2 sql中涉及到的table view index...
Oracle的優化器的RBO和CBO方式
1 基於規則的優化方式 rule based optimization，簡稱為rbo 優化器在分析sql語句時,所遵循的是oracle內部預定的一些規則，對資料是不敏感的。它只借助少量的資訊來決定乙個sql語句的執行計畫，包括 1 sql語句本身 2 sql中涉及到的table view index...
Oracle認證 Oracle優化器的優化方式
oracle是世界領先的資訊管理軟體開發商，因其複雜的關聯式資料庫產品而聞名。本文介紹oracle優化器，它是乙個非常好用的工具。oracle在執行乙個sql之前,首先要分析一下語句的執行計畫,然後再按執行計畫去執行。分析語句的執行計畫的工作是由優化器 optimizer 來完成的。不同的情況,一條...