天天看點

Oracle 12C優化器的巨大變化,上生産必讀(上)

序言

優化器是oracle資料庫最吸引人的部件之一,因為它對每一個sql語句的處理都必不可少。優化器為每個sql語句确定最有效的執行計劃,這是基于給定的查詢的結構,可用的關于底層對象的統計資訊,以及所有與優化器和執行相關的特性。

随着每個新版本的釋出,優化器都會進化,利用新功能以及新的統計資訊來生成更好的執行計劃。随着對查詢優化的新的自适應方法的引入,oracle 12c資料庫把這種進化更推上了一個台階。

這份白皮書介紹了在oracle 12c資料庫中與優化器和統計相關的所有新特性并且提供了簡單的,可再現的例子,使得你能夠更容易地熟悉它們。它還概括了已有的功能是如何被增強以改善性能和易管理性。

優化器和統計資訊新特性

1 自适應查詢優化 

到目前為止,oracle 12c資料庫中最大的變化是自适應查詢優化。自适應查詢優化是這樣的一組功能,它使得優化器能夠對執行計劃進行實時調整,并且發現能夠導緻更佳的統計資訊的額外資訊。當現有的統計資訊不足以産生一個優化的計劃,這種新方法是極其有用的。自适應查詢優化包括兩個方面:自适應計劃,它着重于改善一個查詢的初次執行;自适應統計資訊,它為後續的執行提供了額外的資訊。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖1. 自适應查詢優化功能的元件)

2 自适應計劃 

自适應計劃使得優化器能夠延遲産生一個語句的最終計劃,直到執行的時候才決定。優化器在它所選擇的計劃(預設計劃)中植入統計收集器,進而在運作的時候,它能夠判斷自己的基數估算與計劃的操作所實際看到的行數是否有很大的偏差。如果有顯著的差別,那麼這個計劃或者計劃的一部分在sql語句的首次執行就能夠被自動調整來避免不理想的性能。

3 自适應的連接配接方式 

通過為計劃中的某些分支預先确定多個子計劃,優化器能夠實時調整連接配接方式。例如,在圖2中優化器的初始計劃(預設計劃)為order_items 和 product_info 之間的連接配接標明的是嵌套循環連接配接,通過對product_info表的索引讀取。另一個可選的子計劃也同時被确定,它允許優化器将連接配接方式切換到哈希連接配接。在候選計劃中product_info是通過全表掃描來讀取的。

在執行的時候,統計收集器收集了關于這次執行的資訊,并且将一部分進入到子計劃的資料行緩存起來。在這個例子中,統計收集器監控并緩存了對order_items的全表掃描。基于它在統計收集器中看到的資訊,優化器會最終确定采用哪個子計劃。在這個例子中,哈希連接配接被選為最終計劃,因為來自order_items表的行數大于優化器最初的估計。

在優化器選擇了最終計劃之後,統計收集器停止收集統計資訊以及對資料行的緩存,而僅僅是傳遞資料。在子遊标随後的執行中,優化器禁止了資料緩存,并且選擇了同一個最終計劃。目前的優化器能夠從嵌套連接配接切換到哈希連接配接,反之亦然。可是,如果初始選中的連接配接方法是排序合并連接配接,則自适應不會發生。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖2. 自适應執行計劃确定order_items 和 prod_info 表之間的連接配接)

在預設情況下,explain plan指令隻會顯示優化器標明的初始(預設)計劃。而dbms_xplan.display_cursor隻顯示查詢所用的最終計劃。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖3. explain plan 和 dbms_xplan.display_cursor 為圖2的查詢例子所輸出的計劃)

為了看到自适應計劃中所有的操作,包括統計收集器的位置,你必須在dbms_xplan函數中指定額外的格式參數'+adaptive'。在這個模式下,id欄會出現一個額外的(-)記号,指明在計劃中未被采用(非激活)的操作。在oracle企業管理器(oem)中的sql監控工具總是顯示完整的自适應計劃,但是并沒有指明在計劃中的哪些操作是非激活的。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖4. 在dbms_xplan.display_cursor中使用'+adaptive'格式參數得到的完整自适應計劃)

v$sql中增加了一個新的列(is_resolved_adaptive_plan)來指明一個sql語句是否有自适應計劃,以及該計劃是否已經完全被确定。如果is_resolved_adaptive_plan被設定為'y', 這意味着計劃不僅是自适應的,而且最終計劃已被標明。可是,如果is_resolved_adaptive_plan被設定為'n', 這指明了標明的計劃是自适應的,但是最終計劃仍未被确認。'n'值僅僅在一個查詢的初始執行階段中可見,在此之後,自适應計劃的這個值總是為'y'。對于非自适應計劃這個列被設定為null。

你也可以通過将初始化參數optimizer_adaptive_reporting_only設定為true(預設值是false),進而把自适應連接配接方式置于報告模式。在這個模式下,開啟自适應連接配接方式所需的資訊會被收集,但是改變計劃的任何動作都不會發生。這意味着預設計劃總是會被采用,但是關于計劃在“非報告”模式下會如何調整的資訊将被收集。這個資訊可以在自适應計劃的報告中被檢視,當你用額外的格式參數'+report'顯示計劃的時候就可以看到。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖5. 在dbms_xplan.display_cursor中使用'+report'格式參數所顯示的完整自适應報告)

4 自适應并行配置設定方法 

當一個sql語句以并行模式運作時,某些特定操作,例如排序,聚合和連接配接,它們要求在執行語句的并行服務程序之間重新配置設定資料。優化器所用的配置設定方法取決于操作類型,涉及到的并行服務程序數,以及預期的行數。如果優化器對行數估算不準确,那麼選中的配置設定方法就可能不理想,結果某些并行服務程序就可能得不到充分利用。

随着新的自适應配置設定方法"混合型哈希"(hybrid hash)的引入,優化器可以将配置設定方法的确定延遲到執行的時候才确定,此時它對于涉及到的資料行數就有了更多的資訊。一個統計收集器被插入到操作的前面,如果緩存的資料的實際行數比門檻值小,則配置設定方法将從哈希(hash)切換到廣播(broadcast)。然而,如果緩沖的行數達到了門檻值,則配置設定方法将會是哈希(hash)。門檻值的定義為并行度的兩倍。

圖6顯示了sql監控工具中的一個執行計劃的例子,它是一個以并行模式執行的emp和dept表之間的連接配接。一組并行服務程序(生産者,即粉紅色圖示)掃描兩個表并且将資料送給另一組并行服務程序(消費者,即藍色圖示),該組程序是連接配接的真正執行者。優化器決定采用混合型哈希(hybrid hash)的配置設定方法。在這個連接配接中通路的第一個表是dept表。來自dept表的資料行被緩存在統計收集器中,見計劃的第六行,直至門檻值被超越,或者最後一行被擷取。在那時優化器将會決定采用何種配置設定方法。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖6. sql監控工具中的一個emp和dept表之間的連接配接的執行計劃,它使用了自适應配置設定方法)

我們假定這個例子中的并行度被設定為6, 從dept表掃描傳回的行數是4, 門檻值則是12行(2x6)。既然還未達到門檻值,從dept表傳回的4行将會被廣播到負責完成連接配接的6個并行服務程序,結果計劃中的配置設定步驟所處理的行數是是24行(4x6),見圖7。

既然對于來自dept表的資料行采用了廣播(broadcast)的配置設定方法,來自emp表的資料行将會通過循環制(round-robin)的方法進行配置設定。這意味着來自emp表的一行資料将會輪流發送給6個并行服務程序中的一個,直至所有的資料行都配置設定完畢。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖7. 混合型哈希配置設定法使用廣播的配置設定方式,因為未達到門檻值)

可是,如果這個例子的并行度被設定為2, 而掃描dept表傳回的行數為4, 則門檻值為4行(2x2)。既然已經達到了門檻值,從dept表傳回的4行資料将會以哈希(hash)的方式配置設定到負責完成連接配接的2個并行服務程序, 結果計劃中的配置設定步驟所處理的行數是是4行(見圖8)。既然來自dept表的資料行采用了哈希(hash)配置設定法,來自emp表的資料也會以哈希(hash)方法進行配置設定。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖8. 混合型哈希配置設定法使用哈希的配置設定方式,因為已達到門檻值)

5 自适應統計資訊 

優化器所确定的執行計劃的品質取決于可用的統計資訊的品質。然而,有些查詢謂詞變得過于複雜,以至于無法單獨依賴于基表的統計資訊,而現在優化器能夠用自适應統計資訊來進行增補。

6 動态統計資訊 

在一個sql語句的編譯過程中,優化器會判斷已有的統計資訊是否足以産生一個好的執行計劃,或者它該考慮使用動态取樣。動态取樣是為了補償缺失或者不充足的統計資訊,如果不這麼做,這樣的資訊可能導緻非常糟糕的計劃。在查詢中的一個或者多個表的統計資訊都缺失的情況下,優化器在優化語句之前就會在這些表上使用動态取樣來收集基本的統計資訊。這種情況下收集的統計資訊在品質(因為是取樣)和完整性上都不如使用dbms_stats包收集到的資訊。

在oracle 12c資料庫中, 動态取樣被強化為動态統計資訊。動态統計資訊允許優化器強化現有的統計資訊以擷取更加精确的基數估算,不僅僅是為單表的通路,而且也包含連接配接和分組(group by)謂詞。初始化參數optimizer_dynamic_sampling引入了新的取樣級别11。11級使得優化器能夠自動為任何sql語句使用動态統計資訊,即使所有基本的表統計資訊都已經存在。優化器做出使用動态統計的決定,是基于所用謂詞的複雜性,和已經存在的基礎統計資訊,以及預期的sql語句總執行時間。例如,之前的優化器在某些情況下會使用猜測的方法,比如帶有like謂詞和模糊比對的查詢,而現在則會啟用動态統計資訊。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖9. 當 optimizer_dynamic_sampling 被設為級别 11,動态取樣會被使用,而不是猜測)

在這些新的條件下,當級别設定為11時,動态取樣啟用的頻率很可能超過以往。這會增加語句的解析時間。為了将對性能的影響減到最低,動态取樣查詢的結果将會作為動态統計資訊保留在緩存中,允許其他sql語句來共享這些統計資訊。sql計劃指令(下面将會更詳細地讨論)也會利用這種級别的動态取樣。

7 自動重優化 

和自适應計劃不同的是,在初次執行之後,自動重優化在随後的執行中修改計劃。在一個sql語句的初次執行結束之時,優化器利用初次執行期間收集到的資訊來決定自動重優化是否值得。如果執行的資訊和優化器原有的估計值有顯著差別,則優化器會在下次執行尋求替換的計劃。優化器會利用前一次執行收集到的資訊來幫助确定這個替換計劃。優化器可能将一個查詢重新優化好幾次,每次都學習并且進一步改善計劃。oracle 12c資料庫支援多種不同形式的重優化。

8 統計資訊回報 

統計資訊回報(以前稱為基數回報,cardinality feedback)是重優化的一種形式,它自動為那些反複執行的具有基數估算誤差的查詢改善計劃。在一個sql語句的首次執行期間,優化器生成了一個執行計劃,并且決定是否應該為遊标啟動統計資訊回報螢幕。統計資訊回報在如下的情形被啟用:缺失統計資訊的表,表上有多個合取或者析取謂詞(指and或者or連接配接的謂詞), 謂詞包含有複雜操作,使得優化器不能準确估算基數。

在查詢結束之時,優化器将它原來的基數估算和在執行期間觀測到的實際基數進行比較,如果估算值和實際值有顯著差異,它會将正确的值存儲起來供後續使用。它還會建立一個sql計劃指令,使得其他的sql語句也能受益于這次初始執行中學到的資訊。如果查詢再次執行,優化器會使用糾正過的基數估算值,而不是它原先的估算值,來确定執行計劃。如果它發現初始的估算值是正确的,則不會采取任何額外的措施。在第一次執行之後,優化器關閉了統計資訊回報的監視。

圖10顯示了一個sql語句受益于統計資訊回報的例子。在這個兩表連接配接的初次執行中,由于customers表上有多個相關的單列謂詞,優化器将基數低估了8倍。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖10. 一個受益于自動重優化的統計資訊回報的sql語句初次執行的情況)

在初次執行之後,優化器将它原來的基數估算和計劃中的操作實際傳回的行數進行比較。估計值和實際傳回的行數有很大的差别,是以這個遊标被标記為is_reoptimizible(可重優化)并且不會被再次使用。is_reoptimizible屬性指明這個sql語句應該在下一次執行的時候被硬解析,是以優化器能夠使用在初次執行時記錄下來的統計資訊來确定一個更佳的執行計劃。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖11. 在初次執行的統計資訊與原有的基數估算有顯著差異之後,遊标被辨別為可重優化)

一個sql計劃指令同樣被建立,這是為了確定下次如果在customers表使用了相似的謂詞的sql語句被執行,優化器會注意到這些列之間的相關性。

在第二次執行,優化器使用了來自初次執行的統計資訊來确定一個具有不同連接配接順序的新計劃。在生成執行計劃的過程中對統計資訊回報的使用情況被注明于執行計劃下面的備注部分。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖12. 新生成的計劃使用來自初次執行的統計資訊)

新計劃沒有辨別為is_reoptimizible,是以它将被這個sql語句的所有後續執行所使用。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖13. 新生成的計劃辨別為不可重優化)

9 性能回報 

重優化的另一種形式為性能回報,當自動并行度(autodop)在自适應模式下被啟用,這會有助于改善重複執行的sql語句的并行度的選擇。(注:關于autodop的更多資訊請參照oracle并行執行基礎白皮書)

當自動并行度(autodop)在自适應模式下被啟用,在一個sql語句的首次執行過程中,優化器會決定語句是否應該在并行模式下執行;如果是,應該使用哪種并行度。并行度的選擇是基于語句的預計性能表現。對于優化器決定并行執行的任何sql語句,額外的性能螢幕同樣在初次執行的時候被打開。

在初次執行結束時,優化器選擇的并行度,和根據語句初次執行期間的實際性能統計資訊(例如cpu時間)計算出來的并行度,被加以比較。如果兩個值有顯著差别,那麼語句被辨別為可重優化,初次執行的性能統計資訊被作為回報存儲起來,以幫助為後續的執行計算出一個更加合适的并行度。

如果性能回報被用于一個sql語句,它會在計劃下方的備注部分被注明,如圖14所示。

注意:哪怕autodop不在自适應模式下被啟用,性能回報也可能影響一個語句的并行度選擇。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖14. 一個sql語句的執行計劃,性能回報發現它串行執行會更好)

10  sql計劃指令 

sql計劃指令是根據通過自動重優化學習到的資訊所建立出來的。一個sql計劃指令是一些額外的資訊, 優化器可用來生成一個更優的執行計劃。例如,當發生連接配接的兩個表在連接配接列有傾斜資料,sql計劃指令可以指引優化器使用動态統計資訊來獲得更加精确的連接配接基數估算。

sql計劃指令是在查詢表達式之上建立的,而非語句級或者對象級,這樣就可確定它們可被應用于多個sql語句。在一個sql語句上有多個sql計劃指令也是可能發生的。一個sql語句所使用的sql計劃指令數目被顯示于執行計劃下方的備注部分(圖15)。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖15. 一個語句所使用的sql計劃指令數目被顯示于執行計劃下方的備注部分)

資料庫自動維護sql計劃指令,并把它們存儲在sysaux表空間。任何未被使用的sql計劃指令在53周之後會被自動清除。sql計劃指令也可以通過dbms_spd包手動管理。然而,你不可能手動建立一個sql計劃指令。sql計劃指令可以通過視圖dba_sql_plan_directives和dba_sql_plan_dir_objects進行監控(見圖16)。

如前所述,當圖10所示的sql語句被發現優化器的基數估算和計劃中的操作所傳回的實際行數有顯著差異時,一個sql計劃指令就被建立。實際上,有兩個sql計劃指令被自動建立。一個是為了糾正在customers表上由于多個單列謂詞之間的相關性所導緻的基數估算偏差,一個是為了糾正sales表上的基數估算偏差。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖16. 檢視根據通過自動重優化學習到的資訊所建立出來的sql計劃指令)

在目前僅有一種類型的sql計劃指令,即"動态取樣(dynamic_sampling)"。這會告訴優化器,如果看到了這個特定的查詢表達式(例如,在country_id, cust_city, 和 cust_state_province上一起使用的過濾謂詞),它就應該使用動态取樣來糾正基數估算的偏差。

sql計劃指令同樣被oracle用來确定擴充統計資訊(特别是列群組)是否缺失,是否基數估算偏差能被列群組所糾正。如果是這樣的話,它會在下一次收集統計資訊的時候自動在相應的表上建立那個列群組。于是如果可能的話,擴充資訊就會取代sql計劃指令被使用在sql計劃中(等值謂詞,group by分組等等)。如果sql計劃指令已經沒必要存在,它會在53周後被自動清除。

(注:關于擴充統計資訊的更多資訊可見文章“了解優化器統計資訊”)

舉個例子,在前面的例子中,sql計劃指令16334867421200019996被建立于customers表。這個sql計劃指令被建立的原因是多個單列謂詞之間的相關性。 一個cust_city, cust_state_province,和 country_id上的列群組就可以解決基數估算偏差。下一次收集customers表的統計資訊的時候,這個列群組就會被自動建立。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖17. 基于sql計劃指令自動建立的列群組)

下次這個sql語句被執行的時候,列群組統計資訊就會取代sql計劃指令被使用。dba_sql_plan_directives中的state(狀态)列指明了一個sql計劃指令在這個周期中目前處于哪個環節。

一旦單表的基數估算被解決,額外的sql計劃指令可能被建立于同樣的語句來解決計劃中的其他問題,例如連接配接和分組的基數估算偏差。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖18. 随着時間推移,為圖10中所見的sql語句所建立的多個sql計劃指令)

11 優化器統計資訊 

優化器統計資訊是描述資料庫以及裡面的對象的資料的集合。優化器利用這些統計資訊來為每個sql語句選擇最佳的執行計劃。對于任何一個oracle系統,為了把性能維持在一個可接受的水準,及時收集适當的統計資訊是至關重要的。随着每個新版本的釋出,oracle一直緻力于自動提供必要的統計資訊。

12 新型的直方圖 

直方圖告訴優化器,資料在一個列中是如何分布的。在預設情況下,優化器假定在一個列中,資料行是跨越不同的值均勻分布的, 在帶有等值謂詞查詢中,基數的計算方法是将總行數除以等值謂詞所用到的列中的不同值的個數。直方圖的存在改變了優化器用來确定基數估算的公式,并且允許它生成更精确的估算值。在oracle 12c之前,有兩種類型的直方圖:頻度和等高直方圖。現在多了兩種額外的直方圖,即頂級頻度直方圖和混合直方圖。

13 頂級頻度直方圖 

在過去,如果一個列有超過254個不同值而且指定的桶數為auto, 那麼一個等高直方圖就會被建立。但如果99%或者更多的資料所含有的不同值少于254個,會怎麼樣?如果等高直方圖被建立,那麼就存在這種風險,即不能将表中最頻繁的值捕獲為多個桶的端點值。是以有些頻繁值就會被當作非頻繁值處理,這會導緻不理想的執行計劃被選中。

在這種情況下,為了建立一個品質更加的直方圖,更好的方法是在構成了表中資料的主體的那些極為頻繁的值之上建立一個頻度直方圖,并且忽略那些非頻繁值。一個頻度直方圖被建立于列中最頻繁出現的那些值,當這些值出現在表中99%的資料或者更多。這允許列中所有頻繁出現的值被當作頻繁值來處理。僅當收集統計指令的estimate_percent參數被設定為auto_sample_size時,一個頂級頻度直方圖才會被建立,這是因為列中所有的值都必須被看到,才能确定是否達到必要的标準(99.6%的資料具有254個或者更少的不同的值)。

以product_sales表為例,這個表含有一個聖誕飾物公司的銷售資料。表中有 1.78m 行,共有632個不同的time_id。但是product_sales資料的主體含有少于254個不同的值,因為每年的聖誕飾物主要都在12月銷售。為了讓優化器知道列中的資料發生傾斜,有必要在time_id列上建立一個直方圖。在這個情況下,一個含有254個桶的頂級頻度直方圖被建立。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖19. product_sales表中time_id列資料的分布情況,以及之上所建立的頂級頻度直方圖)

14 混合直方圖 

在前一個版本,當一個列中不同值的個數大于254, 一個等高直方圖就會被建立。在等高直方圖中,隻有在兩個或兩個以上的桶中作為端點出現的值才會被認為是頻繁值。等高直方圖的一個突出問題是,一個頻度落在總群體的1/254和2/254之間的值可能會也可能不會作為一個頻繁值出現。雖然它可能橫跨兩個桶,它可能隻在一個桶中作為端點值出現。這樣的值被認為是近似頻繁值。等高直方圖無法區分近似頻繁值和真正非頻繁值。

混合直方圖類似于傳統的等高直方圖,因為它隻在列中不同值的個數大于254的時候才會被建立。可是,相似性也僅限于此。在混合直方圖中,沒有任何一個值會出現在多個桶的端點,這就允許直方圖包含更多的端點值,實際上也就是比等高直方圖具有更多的桶數。那麼,混合直方圖是如何辨別頻繁值的?每個端點的頻度被記錄下來(在一個新的名為endpoint_repeat_count的列中),這樣就為每個端點值提供了更精确的訓示。

以customers表的cust_city_id列為例。customers表中有55,500行資料,cust_city_id列有620個不同的值。在這種情況下頻度直方圖和頂級頻度直方圖都不合适。在oracle 11g資料庫中,一個等高直方圖将會被建立在這個列上。這個等高直方圖有213個桶但是隻代表了42個頻繁值(出現在2個或更多的桶的端點的值)。cust_city_id列中實際的頻繁值個數是54(即,出現頻度大于總行數/桶數=55500/254的那些值有54個)。

在oracle 12c資料庫中,一個混合直方圖會被建立。混合直方圖有254個桶,并且代表了所有54個頻繁值。實際上混合直方圖将63個值當作頻繁值。這意味着在oracle 11g資料庫中被當作近似頻繁值(隻在一個桶中作為端點值)現在被處理為頻繁值,并且将會有更精确的基數估算。圖20顯示了一個例子,在oracle 11g資料庫中的一個近似頻繁值(52114)如何在oracle 12c資料庫中得到更佳的基數估算。

在 cust_city_id=52114的資料總共有227行:

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖 20. 混合直方圖使得那些oracle 11g資料庫中被當作近似頻繁值的值得到更精确的基數估算)

15 統計資訊線上收集 

當一個索引被建立,全表掃描是必不可少的,oracle順便加上統計資訊的收集,将自動收集優化器統計資訊作為索引建立任務的一部分。現在,同樣的技術也被應用于直接路徑操作,例如create table as select (ctas)和insert as select(ias)操作。将統計資訊收集搭載為資料加載操作的一部分,意味着在資料加載結束之後,不需要額外的全表掃描就可以立即擁有統計資訊。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖21. 統計資訊線上收集為新建立的sales2表同時提供了表統計和列統計資訊)

統計資訊線上收集并不包括收集直方圖或者索引統計,因為這些類型的統計資訊需要額外的掃描,這可能會對資料加載的性能造成很大的影響。為了收集必要的直方圖和索引統計,而無需重新收集基礎列統計資訊,請使用dbms_stats.gather_table_stats過程并将options參數設定為新的gather auto選項。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖22. 将 options 設為 gather auto 在sales2表上建立了直方圖而無需收集基礎統計資訊)

備注列中的“histogram_only”指明直方圖在沒有重新收集基礎列統計的情況下被收集。gather auto選項僅在統計資訊的線上收集發生之後被推薦使用。

有兩種方法可以确定統計資訊的線上收集是否發生:檢查執行計劃,看看新的資料源optimizer statistics gathering是否在計劃中出現,或者檢視user_tab_col_statistics表的新的notes列,看看是否有狀态值stats_on_load。

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖23. 統計資訊線上收集操作的執行計劃)

根據設計,統計資訊線上收集對直接路徑操作的性能影響要最小化,是以它隻能發生于空對象的資料加載。在向一張現有的表的新的分區中加載資料的時候,為了確定統計資訊線上收集能夠發生,請使用擴充的文法來顯式指定分區。在這種情況下,分區級别的統計資訊會被建立,但是全局(表級别)統計資訊不會被修改。如果增量統計資訊在分區表上被打開,一份綱要也會作為資料加載的一部分被建立。(譯注: 綱要(synopsis)是在表分區級别收集的輔助統計資訊,包含這個分區的某個列的不同值(ndv)的清單,根據這個資訊可以推算出全表的不同值)

Oracle 12C優化器的巨大變化,上生産必讀(上)

(圖24. 在往現有分區表插入操作時發生了統計資訊線上收集)

注意,在語句級别指定提示no_gather_optimizer_statistics可以關閉統計資訊線上收集。

------------------未完待續------------------

譯者介紹  蘇旭輝

網絡id:newkid,從事it行業20餘年,現定居加拿大多倫多;

oracle資深開發大師,幫助過無數網友解決過oracle疑難問題;

《劍破冰山-oracle開發藝術》副主編。

作者:maria colgan

<b></b>

<b>本文來自雲栖社群合作夥伴"dbaplus",原文釋出時間:2016-04-27</b>