2. 程式人生 > >陳煥生：深入理解Oracle 的並行執行

陳煥生：深入理解Oracle 的並行執行

阿新 • • 發佈：2019-02-05

Oracle並行執行是一種分而治之的方法。執行一個sql 時，分配多個並行程序同時執行資料掃描，連線以及聚合等操作，使用更多的資源，得到更快的sql 響應時間。並行執行是充分利用硬體資源，處理大量資料時的核心技術。

在本文中，在一個簡單的星型模型上，我會使用大量例子和sql monitor 報告，力求以最直觀簡單的方式，向讀者闡述並行執行的核心內容：

• Oracle 並行執行為什麼使用生產者——消費者模型。
• 如何閱讀並行執行計劃。
• 不同的資料分發方式分別適合什麼樣的場景。
• 使用partition wise join 和並行執行的組合提高效能。
• 資料傾斜會對不同的分發方式帶來什麼影響。
• 由於生產者-­‐消費者模型的限制，執行計劃中可能出現阻塞點。
• 布隆過濾是如何提高並行執行效能的。
• 現實世界中，使用並行執行時最常見的問題。

術語說明：

  1. S： 時間單位秒。
  2. K： 數量單位一千。
  3. M： 數量單位一百萬， 或者時間單位分鐘。
  4. DoP： Degree of Parallelism， 並行執行的並行度。
  5. QC： 並行查詢的 Query Coordinator。
  6. PX 程序： Parallel Execution Slaves。
  7. AAS： Average active session， 並行執行時平均的活動會話數。
  8. 分發： pq distribution method， 並行執行的分發方式， 包括 replicate， broadcast， hash 和 adaptive分發等 4 種方式， 其中 adaptive 分發是 12c 引入的的新特性， 我將在本篇文章中一一闡述。
  9. Hash join 的左邊： 驅動表， the build side of hash join， 一般為小表。
  10. Hash join 的右邊： 被驅動表， the probe side of hash join， 一般為大表。
  11. 布隆過濾： bloom filter， 一種記憶體資料結構， 用於判斷一個元素是否屬於一個集合。

測試環境和資料

Oracle版本為12.1.0.2.2，兩個節點的RAC，硬體為ExadataX3-­‐8。

這是一個典型的星型模型，事實表lineorder有3億行記錄，維度表part/customer分別包含1.2M

和1.5M行記錄，3個表都沒有進行分割槽，lineorder大小接近30GB。


[js] view plaincopyprint?在CODE上檢視程式碼片派生到我的程式碼片
  1. select
  2. owner seg_owner，
  3. segment_name seg_segment_name， round(bytes/1048576，2) SEG_MB
  4. from
  5. dba_segments where
  6. owner = 'SID'
  7. and segment_name in ('LINEORDER'，'PART'，'CUSTOMER')
  8. /
  9. OWNER SEGMENT_NAME SEGMENT_TYPE SEG_MB
  10. ------ ------------ ------------ -------- SID LINEORDER TABLE 30407.75
  11. SID CUSTOMER TABLE 168
  12. SID PART TABLE 120

本篇文章所有的測試，除非特別的說明，我關閉了12c的adaptive plan特性，引數optimizer_adaptive_features被預設設定為false。Adaptive相關的特性如cardinality feedback，adaptive distribution method，adaptive join都不會啟用。如果檢查執行計劃的outline資料，你會發現7個優化器相關的隱含引數被設定為關閉狀態。事實上，12c優化器因為引入adaptive plan特性，比以往版本複雜得多，剖析12c的優化器的各種新特性，我覺得非常具有挑戰性，或許我會在另一篇文章裡嘗試一下。

[js] view plaincopyprint?在CODE上檢視程式碼片派生到我的程式碼片
  1. select * from table(dbms_xplan.display_cursor('77457qc9a324k',0,’outline’));
  2. ...
  3. Outline Data
  4. -------------
  5. /*+
  6. BEGIN_OUTLINE_DATA
  7. IGNORE_OPTIM_EMBEDDED_HINTS
  8. OPTIMIZER_FEATURES_ENABLE('12.1.0.2')
  9. DB_VERSION('12.1.0.2')
  10. OPT_PARAM('_optimizer_use_feedback' 'false')
  11. OPT_PARAM('_px_adaptive_dist_method' 'off')
  12. OPT_PARAM('_optimizer_dsdir_usage_control' 0)
  13. OPT_PARAM('_optimizer_adaptive_plans' 'false')
  14. OPT_PARAM('_optimizer_strans_adaptive_pruning' 'false')
  15. OPT_PARAM('_optimizer_gather_feedback' 'false')
  16. OPT_PARAM('_optimizer_nlj_hj_adaptive_join' 'false')
  17. OPT_PARAM('optimizer_dynamic_sampling' 11)
  18. ALL_ROWS
  19. ……
  20. END_OUTLINE_DATA
  21. */

並行初體驗

序列執行

以下sql對customers和lineorder連線之後，計算所有訂單的全部利潤。 序列執行時不使用parallel hint：

[js] view plaincopyprint?在CODE上檢視程式碼片派生到我的程式碼片
  1. select /*+ monitor */
  2. sum(lo_revenue)
  3. from
  4. lineorder, customer
  5. where
  6. lo_custkey = c_custkey;

序列執行時，sql執行時間為1.5分鐘，dbtime為1.5分鐘。執行計劃有5行，一個使用者程序工作完成了對customer，lineorder兩個表的掃描，hashjoin，聚合以及返回資料的所有操作。此時AAS(average active sessions)為1，sql執行時間等於db time。幾乎所有的dbtime都為db cpu，72%的cpu花在了第二行的hash join操作。因為測試機器為一臺Exadata X3——8，30GB的IO請求在一秒之內處理完成。Celloffload Efficiency等於87%意味著經過儲存節點掃描，過濾不需要的列，最終返回計算節點的資料大小隻有30GB的13%。


並行執行

使用hint parallel(4)，指定DoP=4並行執行同樣的sql：

[js] view plaincopyprint?在CODE上檢視程式碼片派生到我的程式碼片
  1. select /*+ monitor parallel(4)*/
  2. sum(lo_revenue)
  3. from
  4. lineorder, customer
  5. where
  6. lo_custkey = c_custkey;

SQL執行時間為21s，db time為1.4分鐘。DoP=4，在兩個例項上執行。執行計劃從5行增加為9行，從下往上分別多了’PXBLOCKITERATOR’， ‘SORTAGGREGATE’， ‘PXSENDQC(RANDOM)’ 和 ’PXCOORDINATOR’ 這四個操作。

其中3到8行的操作為並行處理，sql的執行順序為：每個PX程序掃描維度表customer(第6行)，以資料塊地址區間作為單位(第7行)掃描四分之一的事實表lineorder(第8行)，接著進行hash join(第5行)，然後對連線之後的資料做預先聚合(第4行)，最後把結果給QC(第三行)。QC接收資料(第2行)之後，做進一步的彙總(第1行)，最後返回資料(第0行)。

SQL執行時間比原來快了4倍，因為最消耗時間的操作，比如對lineorder的全表掃描，hashjoin和聚合，我們使用4個程序並行處理，因此最終sql執行時間為序列執行的1/4。另一方面，dbtime並沒有明顯下降，並行時1.4m，序列時為1.5m，從系統的角度看，兩次執行消耗的系統資源是一樣的。


DoP=4時，因為沒有涉及資料的分發(distribution)，QC只需分配一組PX程序，四個PX程序分別為例項1和2的p000/p0001。我們可以從系統上檢視這4個PX程序。每個PX程序消耗大致一樣的db time，CPU和IO資源。AAS=4，這是最理想的情況，每個PX程序完成同樣的工作量，一直保持活躍。沒有序列點，沒有並行執行傾斜。

AAS=4，檢視活動資訊時，為了更好的展示活動資訊，注意點掉”CPU Cores”這個複選框。


在Linux系統上顯示這四個PX程序。

[js] view plaincopyprint?在CODE上檢視程式碼片派生到我的程式碼片
  1. [[email protected] sidney]$ ps -ef | egrep "p00[01]_SSB"
  2. oracle 20888 1 4 2014 ? 18:50:59 ora_p000_SSB1
  3. oracle 20892 1 4 2014 ? 19:01:29 ora_p001_SSB1
  4. [[email protected] sidney]$ ssh exa01db02 'ps -ef | egrep "p00[01]_SSB"'
  5. oracle 56910 1 4 2014 ? 19:01:03 ora_p000_SSB2
  6. oracle 56912 1 4 2014 ? 18:53:30 ora_p001_SSB2

小結

本節的例子中，DoP=4，並行執行時分配了4個PX程序，帶來4倍的效能提升。SQL monitor報告包含了並行執行的總體資訊和各種細節，比如QC，DoP，並行執行所在的例項，每個PX程序消耗的資源，以及執行SQL時AAS。

生產者-消費者模型

在上面並行執行的例子中，每個px程序都會掃描一遍維度表customer，然後掃描事實表lineorder進行hash join。這時沒有資料需要進行分發，只需要分配一組px程序。這種replicate維度表的行為，是12c的新特性，由引數_px_replication_enabled控制。

更常見情況是並行執行時，QC需要分配兩組PX程序，互為生產者和消費者協同工作，完成並行執行計劃。架構圖1如下：


Broadcast分發，一次資料分發

為了舉例說明兩組px程序如何協作的，設定_px_replication_enabled為false。QC會分配兩組PX程序，一組為生產者，一組為消費者。

見下圖，此時sql執行時間為23s，執行時間變慢了2s，dbtime仍為1.5分鐘。


最大的變化來自執行計劃，現在執行計劃有12行。增加了對customer的並行掃描 PXBLOCKITERATOR (第8行)，分發’PXSENDBROADCAST’和接收’PXRECEIVE’。執行計劃中出現了兩組PX程序，除了之前藍色的多人標誌，現在出現了紅色的多人標誌。此時，SQL的執行順序為：

  1. 4個紅色的PX程序扮演生產者角色，掃描維度表customer，把資料通過broadcast的方式分發給每一個扮演消費者的藍色PX程序。因為DoP=4，每一條被掃描出來的記錄被複制了4份，從sqlmonitor的第9行，customer全表掃描返回1。5m行資料，第8行的分發和第7行的接受之時，變成了6m行記錄，每個作為消費者的藍色px程序都持有了一份完整包含所有custome記錄的資料，並準備好第5行hashjoin的buildtable。
  2. 4個作為消費者的藍色PX程序，以資料塊地址區間為單位掃描事實表lineorder(第10/11行);同時和已經持有的customer表的資料進hashjoin(第5行)，然後對滿足join條件的資料做預聚合(第4行)，因為我們查詢的目標是對所有lo_revenue求和，聚合之後每個PX程序只需輸出一個總數。
  3. 4個藍色的PX程序反過來作為生產者，把聚合的資料發給消費者QC(第3行和第2行)。由QC對接收到4行記錄做最後的聚合，然後返回給使用者。
  4. 使用broadcast的分發方式，只需要把customer的資料廣播給每個消費者。Lineorder的數不需要重新分發。因為lineorder的資料量比customer大的多，應該避免對lineorder的資料進行分發，這種執行計劃非常適合星型模型的資料。

觀察sql monitor報告中Parallel標籤下的資訊，紅色的PX程序為例項1、2上的p002/p003程序，藍色的PX程序為p000/p001程序，因為藍色的PX程序負責掃描事實表lineorder，hash join和聚合，所以消耗幾乎所有的db time。


生產者-消費者模型工作原理

並行查詢之後，可以通過檢視V$PQ_TQSTAT，驗證以上描述的執行過程。

  1. 例項1、2上的p002/p003程序作為生產者，幾乎平均掃描customer的1/4記錄，把每一條記錄廣播給4個消費者PX程序，傳送的記錄數之和為6m行。通過table queue0(TQ_ID=0)，每個作為消費者的p000/p001程序，接收了完整的1。5m行customer記錄，接收的記錄數之和為6m行。
  2. 例項1、2上的p000/p0001程序作為生產者，通過table queue1(TQ_ID=1)，把聚合的一條結果記錄發給作為消費者的QC。QC作為消費者，接收了4行記錄。
[js] view plaincopyprint?在CODE上檢視程式碼片派生到我的程式碼片
  1. SELECT
  2. dfo_number, tq_id, server_type, instance, process, num_rows
  3. FROM
  4. V$PQ_TQSTAT
  5. ORDER BY
  6. dfo_number DESC, tq_id, server_type desc, instance, process;
  7. DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS
  8. ---------- ---------- -------------- ---------- --------- ----------
  9. 1 0 Producer 1 P002 1461932
  10. 1 0 Producer 1 P003 1501892
  11. 1 0 Producer 2 P002 1575712
  12. 1 0 Producer 2 P003 1460464
  13. 1 0 Consumer 1 P000 1500000
  14. 1 0 Consumer 1 P001 1500000
  15. 1 0 Consumer 2 P000 1500000
  16. 1 0 Consumer 2 P001 1500000
  17. 1 1 Producer 1 P000 1
  18. 1 1 Producer 1 P001 1
  19. 1 1 Producer 2 P000 1
  20. 1 1 Producer 2 P001 1
  21. 1 1 Consumer 1 QC 4
  22. 13 rows selected.

那麼，以上的輸出中，DFO_NUMBER和TQ_ID這兩列表示什麼意思呢?

  1. DFO代表Data Flow Operator，是執行計劃中可以並行執行的操作。一個QC代表一棵DFO樹(tree)，包含多個DFO;同一個QC中所有並行操作的DFO_NUMBER是相同的，此例中，所有DFO_NUMBER為1。執行計劃包含多個QC的例子也不少見，比如使用unionall的語句，unionall每個分支都是獨立的DFO樹，不同的DFO樹之間可以並行執行。本篇文章僅討論執行計劃只有一個QC的情況。
  2. TQ代表table queue，用以PX程序之間或者和QC通訊連線。以上執行計劃中，table queue0為PX程序之間的連線，table queue1為PX程序和QC之間的連線。生產者通過table queue分發資料，消費者從tablequeue接收資料。不同的table queue編號，代表了不同的資料分發。通過table queue，我們可以理解Oracle並行執行使用生產者-­‐消費者模型的本質：
  • 同一棵DFO樹中，最多隻有兩組PX程序。每個生產者程序都存在一個和每個消費者程序的連線，每個PX程序和QC都存在一個連線。假設DoP=n，連線總數為(n*n+2*n)，隨著n的增長，連線總數會爆炸型增長。Oracle並行執行設計時，採用生產者和消費者模型，考慮到連線數的複雜度，每個DFO最多隻分配兩組PX程序。假設DoP=100時，兩組PX程序之間的連線總數為10000。假設可以分配三組PX程序一起完成並行執行計劃，那麼三組PX之間連線總數會等於1百萬，維護這麼多連線，是一個不可能的任務。
  • 同一棵DFO樹中，兩組PX程序之間，同一時間只存在一個活躍的資料分發。如果執行路徑很長，資料需要多次分發，兩組PX程序會變換生產者消費者角色，相互協作，完成所有並行操作。每次資料分發，對應的tablequeue的編號不同。一個活躍的資料分發過程，需要兩組PX程序都參與，一組為生產者傳送資料，一組為消費者接收資料。因為一個DFO裡最多隻有兩組PX程序，意味著，PX程序之間，同一時間只能有一個活躍的資料分發。如果PX程序在執行計劃中需要多次分發資料，可能需要在執行計劃插入一些阻塞點，比如BUFFERSORT和HASHJOINBUFFERED這兩個操作，保證上一次的資料分發完成之後，才開始下一次分發。在後面的章節，我將會說明這些阻塞點帶來什麼影響。這個例子中，tablequeue0和1可以同時工作是因為：tablequeue0是兩組PX程序之間的連結，tablequeue1為PX程序和QC之間的連線，tablequeue0與tablequeue1是相互獨立的，因此可以同時進行。
  • PX程序之間或者與QC的連線至少存在一個(單節點下至多三個，RAC環境下至多四個)訊息緩衝區用於程序間資料互動，該訊息緩衝區預設在Largepool中分配(如果沒有配置Largepool則在Sharedpool中分配)。多個緩衝區是為了實現非同步通訊，提高效能。
  • 每個訊息緩衝區的大小由引數parallel_execution_message_size控制，預設為16k。
  • 當兩個程序都在同一個節點的時候，通過在Largepool(如果沒有配置Largepool則Sharedpool)中傳遞和接收訊息緩衝進行資料互動。當兩個程序位於不同節點時。通過RAC心跳網路進行資料互動，其中一方接收的資料需要快取在本地Largepool(如果沒有配置Largepool則Sharedpool)裡面。

小結

為了說明並行執行的生產者--消費者模型是如何工作的，我使用了broad cast分發，QC分配兩組PX程序，一組為生產者，一組為消費者。QC和PX程序之間，兩組PX程序之間通過table queue進行資料分發，協同完成整個並行執行計劃。檢視V$PQ_TQSTAT記錄了並行執行過程中，資料是如何分發的。通過對DFO，table queue的描述，我闡述生產者-­‐消費者模型的工作原理和通訊過程，或許有些描述對你來說過於突然，不用擔心，後面的章節我會通過更多的例子來輔助理解。

如何閱讀並行執行計劃

Table queue 的編號代表了並行執行計劃中，資料分發的順序。理解執行計劃中的並行操作是如何被執行的，原則很簡單：跟隨Tablequeue的順序。

通過sqlmonitor報告判斷sql的執行順序，需要結合name列的tablequeue名字比如：TQ10000(代表DFO=1，tablequeue0)，：TQ10001(代表DFO=1，tablequeue1)，還有PX程序的顏色，進行確定。

下面的例子為dbms_xplan。display_cursor 的輸出。對於並行執行計劃，會多出來三列：

1. TQ列：為Q1：00或者Q1：01，其中Q1代表第一個DFO，00或者01代表tablequeue的編號。

a. ID7~9的操作的TQ列為Q1，00，該組PX程序，作為生產者首先執行，然後通過broadcast 的分發方式，把資料發給消費者。

b. ID10~11，3~6的操作的TQ列為Q1，01，該組PX程序作為消費者接受customer的資料之後，掃描lineorder，hashjoin，聚合之後，又作為生產者通過tablequeue2把資料發給QC。

2. In-­‐out 列：表明資料的流動和分發。

•PCWC：parallelcombinewithchild。

•PCWP：parallelcombinewithparent。

•P-­‐>P： paralleltoparallel。

•P-­‐>S： paralleltoSerial。

3. PQDistribute 列：資料的分發方式。此執行計劃中，我們使用了broadcast 的方式，下面的章節

我會講述其他的分發方式。


HASH分發方式， 兩次資料分發

除了broadcast分發方式，另一種常見的並行分發方式為hash。為了觀察使用hash分發時sql的 執行情況，我對sql使用pq_distributehint。

[js] view plaincopyprint?
  1. select /*+ monitor parallel(4)
  2. leading(customer lineorder)
  3. use_hash(lineorder)
  4. pq_distribute(lineorder hash hash) */
  5. sum(lo_revenue)
  6. from
  7. lineorder, customer
  8. where
  9. lo_custkey = c_custkey;

使用hash分發方式時，sql的執行時間為29s，dbtime為2.6m。相對於broadcast方式，sql的執行時間和dbtime都增加了大約40%。

執行計劃如下，執行計劃為14行，增加了對lineorder的hash分發，第11行的’PXSENDHASH’對3億行資料通過hash函式分發，第10行的’PXRECEIVE’通過tablequeue1接收3億行資料，這兩個操作消耗了38%的dbcpu。這就是為什麼SQL執行時間和dbtime變長的原因。此時，SQL的執行順序為：

  1. 紅色的PX程序作為生產者，並行掃描customer(第8~9行)，對於連線鍵c_custkey運用函式，根據每行記錄的hash值，通過tablequeue0，發給4個藍色消費者的其中一個(第7行)。Hash分發方式並不會複製資料，sqlmonitor報告的第6~9行，actualrows列都為1.5m。
  2. 紅色的PX程序作為生產者，並行掃描li neorder(第12~13行)，對於連線鍵lo_custkey運用同樣的dhash函式，通過tablequeue1，發給4個藍色消費者的其中一個(第11行)。同樣的hash函式保證了customer和lineorder相同的連線鍵會發給同一個消費者，保證hashjoin結果的正確。因為3億行資料都需要經過hash函式計算，然後分發(這是程序間的通訊，或者需要通過RAC心跳網路通訊)，這些巨大的額外開銷，就是增加38%cpu的原因。

  3. 4個藍色的PX程序作為消費者接收了customer的1.5M行記錄(第 6 行)，和lineorder的3億行記錄(第10行)，進行hash join(第5行)，預聚合(第4行)。

  4. 4個藍色的PX程序反過來作為生產者，通過table queue2，把聚合的資料發給消費者QC(第3 行和第2行)。由QC對接收到4行記錄做最後的聚合， 然後返回給使用者(第1和0行)。

觀察sql monitor報告中Parallel標籤下的資訊，紅色的px程序為例項1、2上的p002/p003程序，藍色的PX程序為p000/p001程序。作為生產者的紅色PX程序負責掃描事實表lineorder，對3億行資料進行hash分發，佔了超過1/3的db time。


因為涉及3億行資料的分發和接收，作為生產者的紅色PX程序和作為消費者的藍色PX程序需要同時活躍，SQL monitor報告中的activity資訊顯示大部分時間，AAS超過並行度4，意味這兩組PX程序同時工作。不像replicate或者broadcast分發時，AAS為4，只有一組PX程序保持活躍。


[js] view plaincopyprint?
  1. SELECT
  2. dfo_number, tq_id, server_type, instance, process, num_rows
  3. FROM
  4. V$PQ_TQSTAT
  5. ORDER BY
  6. dfo_number DESC, tq_id, server_type desc, instance, process;
  7. DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS
  8. ---------- ---------- -------------- ---------- --------- ----------
  9. 1 0 Producer 1 P002 299928364
  10. 1 0 Producer 1 P003 299954384
  11. 1 0 Producer 2 P002 300188788
  12. 1 0 Producer 2 P003 299951708
  13. 1 0 Consumer 1 P000 300005811
  14. 1 0 Consumer 1 P001 300005811
  15. 1 0 Consumer 2 P000 300005811
  16. 1 0 Consumer 2 P001 300005811
  17. 1 1 Producer 1 P000 1
  18. 1 1 Producer 1 P001 1
  19. 1 1 Producer 2 P000 1
  20. 1 1 Producer 2 P001 1
  21. 1 1 Consumer 1 QC 4
  22. 13 rows selected.
[js] view plaincopyprint?
  1. select /*+ monitor parallel(4)*/
  2. sum(lo1.lo_revenue)
  3. from
  4. lineorder_hash32 lo1, lineorder_hash32 lo2
  5. where
  6. lo1.lo_orderkey = lo2.lo_orderkey;

並行查詢之後，通過檢視V$PQ_TQSTAT，進一步驗證以上描述的執行過程。並行執行過程涉及3

個tablequeue0/1/2，V$PQ_TQSTAT包含21行記錄。

1.　例項1、2上的p002/p003程序作為生產者，平均掃描customer的1/4記錄，然後通過tablequeue0(TQ_ID=0)，發給作為消費者的p000/p001程序。傳送和接收的customer記錄之和都為 1.5m。

• 傳送的記錄數：1500000= 365658+364899+375679+393764

• 接收的記錄數：1500000= 374690+374924+375709+374677

2. 　例項1、2上的p002/p0003程序作為生產者，平均掃描lineorder的1/4記錄，通過table queue1(TQ_ID=1) ，發給作為消費者的p000/p001程序。傳送和接收的lineorder 記錄之和都為300005811。

• 傳送的記錄數：300005811= 74987629+75053393+74979748+74985041

• 接收的記錄數：300005811= 74873553+74968719+75102151+75061388

3.　例項1、2上的p000/p0001程序作為生產者，通過tablequeue2(TQ_ID=2)，把聚合的一條結果記 錄發給作為消費者的QC。QC作為消費者，接收了4行記錄。

[js] view plaincopyprint?
  1. SELECT
  2. dfo_number, tq_id, server_type, instance, process, num_rows
  3. FROM
  4. V$PQ_TQSTAT
  5. ORDER BY
  6. dfo_number DESC, tq_id, server_type desc, instance, process;
  7. DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS
  8. ---------- ---------- ---------------- ---------- --------- ----------
  9. 1 0 Producer 1 P002 365658
  10. 1 0 Producer 1 P003 364899
  11. 1 0 Producer 2 P002 375679
  12. 1 0 Producer 2 P003 393764
  13. 1 0 Consumer 1 P000 374690
  14. 1 0 Consumer 1 P001 374924
  15. 1 0 Consumer 2 P000 375709
  16. 1 0 Consumer 2 P001 374677
  17. 1 1 Producer 1 P002 74987629
  18. 1 1 Producer 1 P003 75053393
  19. 1 1 Producer 2 P002 74979748
  20. 1 1 Producer 2 P003 74985041
  21. 1 1 Consumer 1 P000 74873553
  22. 1 1 Consumer 1 P001 74968719
  23. 1 1 Consumer 2 P000 75102151
  24. 1 1 Consumer 2 P001 75061388
  25. 1 2 Producer 1 P000 1
  26. 1 2 Producer 1 P001 1
  27. 1 2 Producer 2 P000 1
  28. 1 2 Producer 2 P001 1
  29. 1 2 Consumer 1 QC 4
  30. 21 rows selected.

小結

陣列大小m，可以把錯誤判斷的機率控制在很小的範圍之內。

我們觀察hash分發時sql的並行執行過程。Hash分發與broadcast最大的區分在於對hashjoin的兩邊都進行分發。這個例子中，對lineorder的hash分發會增加明顯的dbcpu。下一節，我將使用另一個例子，說明hash分發適用的場景。

Replicate，Broadcast和Hash的選擇

我們已經測試過replicate，broadcast，和hash這三種分發方式。

  1. Replicate ：每個PX程序重複掃描hashjoin的左邊，buffercache被用來快取hashjoin左邊的小表，減少重複掃描所需的物理讀。相對於broadcast分發，replicate方式只需一組PX程序。但是replicate不能替換broadcast分發。因為repli cate僅限於hashjoin左邊是表的情況，如果 hashjoin的左邊的結果集來自其他操作，比如join或者檢視，那麼此時無法使用replicate。

  2. Broadcast分發：作為生產者的PX程序通過廣播的方式，把hashjoin左邊的結果集分發給每 個作為消費者的PX程序。一般適用於hashjoin左邊結果集比右邊小得多的場景，比如星型模型。

  3. Hash分發的本質：把hashjoin的左邊和右邊(兩個資料來源)，通過同樣hash函式重新分發，切 分為N個工作單元(假設DoP=N)，再進行join ，目的是減少PX程序進行join操作時，需要連線的資料量。Hash分發的代價需要對hashjoin的兩邊都進行分發。對於customer連線lineorder的例子，因為維度表customer的資料量比事實表lineorder小得多，對customer進行replicate或者broadcast分發顯然是更好的選擇，因為這兩種方式不用對lineorder進行重新分發。如果是兩個大表join的話，join操作會是整個執行計劃的瓶頸所在，hash分發是唯一合適的方式。為了減低join的代價，對hashjoin左邊和右邊都進行hash分發的代價是可以接受的。

Hash分發，有時是唯一合理的選擇

我們使用lineorder上的自連線來演示，為什麼有時hash分發是唯一合理的選擇。測試的SQL如 下：

[js] view plaincopyprint?
  1. select /*+ monitor parallel(4)*/
  2. sum(lo1.lo_revenue)
  3. from
  4. lineorder lo1, lineorder lo2
  5. where
  6. lo1.lo_orderkey = lo2.lo_orderkey;

SQL執行時間為2.4分鐘，dbtime為10.5分鐘。


優化器預設選擇hash分發方式，執行計劃為14行，結構與之前的Hash分發的例子是一致的。不 同的是，第5行的hash join消耗了73%的db time，使用了9GB的臨時表空間，表空間的IO佔12%的db time。大約15%的db time用於Lineorder的兩次hash分發和接收，相對上一個例子的佔38%比例，這兩次HASH分發的整體影響降低了一倍多。


紅色的PX程序為例項1、2上的p002/p003程序，藍色的PX程序為p000/p001程序。作為生產者的紅色PX程序佔總db time的15%左右。


SQL執行開始，對lineorder兩次hash分發時，AAS大於4，分發完成之後，只有藍色的PX程序進行 hash join操作，AAS=4。


從V$PQ_TQSTAT檢視可以確認，對於lineorder的存在兩次分發，通過table queue0和1，作為消費者的4個PX程序接收到的兩次資料是一樣的，保證重新分發不會影響join結果的正確性。每個藍色PX 程序需要hash join的左邊和右邊均為3億行資料的1/4，通過hash分發，3億行記錄連線3億行記錄的工作平均的分配四個獨立PX程序各自處理，每個PX程序處理75M行記錄連線75M行記錄。

[js] view plaincopyprint?
  1. SELECT
  2. dfo_number, tq_id, server_type, instance, process, num_rows
  3. FROM
  4. V$PQ_TQSTAT
  5. ORDER BY
  6. dfo_number DESC, tq_id, server_type desc, instance, process;
  7. DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS
  8. ---------- ---------- -------------- ---------- --------- ----------
  9. 1 0 Producer 1 P002 75055725
  10. 1 0 Producer 1 P003 74977459
  11. 1 0 Producer 2 P002 74995276
  12. 1 0 Producer 2 P003 74977351
  13. 1 0 Consumer 1 P000 74998419
  14. 1 0 Consumer 1 P001 74995836
  15. 1 0 Consumer 2 P000 74976974
  16. 1 0 Consumer 2 P001 75034582
  17. 1 1 Producer 1 P002 74986798
  18. 1 1 Producer 1 P003 74985268
  19. 1 1 Producer 2 P002 74984883
  20. 1 1 Producer 2 P003 75048862
  21. 1 1 Consumer 1 P000 74998419
  22. 1 1 Consumer 1 P001 74995836
  23. 1 1 Consumer 2 P000 74976974
  24. 1 1 Consumer 2 P001 75034582
  25. 1 2 Producer 1 P000 1
  26. 1 2 Producer 1 P001 1
  27. 1 2 Producer 2 P000 1
  28. 1 2 Producer 2 P001 1
  29. 1 2 Consumer 1 QC 4
  30. 21 rows selected.

使用 broadcast 分發，糟糕的效能

對於lineorder,lineorder的自連線， 如果我們使用broadcast分發，會出現什麼情況呢?我們測試一下：

[js] view plaincopyprint?
  1. select /*+ monitor parallel(4)
  2. leading(lo1 lo2)
  3. use_hash(lo2)
  4. pq_distribute(lo2 broadcast none) */
  5. 15
  6. sum(lo1.lo_revenue)
  7. from
  8. lineorder lo1, lineorder lo2
  9. where
  10. lo1.lo_orderkey = lo2.lo_orderkey;

使用broadcase分發，SQL的執行時間為5.9分鐘，db time為23.8分鐘。相比hash分發，執行時間和 db time都增加了接近1.5倍。


紅色的PX程序作為生產者，對lineorder進行並行掃描之後，3億行記錄通過tablequeue0廣播給4個作為消費者的藍色PX程序(第6~9行)，相當於複製了4份，每個藍色的PX程序都接收了3億行記錄.這次broadcast分發消耗了11%的db time，因為需要每行記錄傳輸給每個藍色PX程序，消耗的db cpu比使用hash分發時兩次hash分發所消耗的還多。

第5行的hash join的所消耗的臨時表空間上升到27GB，臨時表空間IO佔的db time的38%。因為每個藍色PX程序進行hash join的資料變大了，hash join的左邊為3億行資料，hash join的右邊為3億行記錄的1/4.


藍色PX程序為消費者負責hash join，所消耗的db time都大幅增加了。


hash join時，臨時表空間讀等待事件’direct path read temp’明顯增加了。

V$PQ_TQSTAT的輸出中，例項1、2上的p000/p001程序作為消費者，都接收了3億行資料，造成後續hash join的急劇變慢。Broadcast分發對hash join左邊進行廣播的機制，決定了它不適合hash join兩邊都為大表的情況。

[js] view plaincopyprint?
  1. SELECT
  2. dfo_number, tq_id, server_type, instance, process, num_rows
  3. FROM
  4. V$PQ_TQSTAT
  5. ORDER BY
  6. dfo_number DESC, tq_id, server_type desc, instance, process;
  7. DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS
  8. ---------- ---------- -------------- ---------- --------- ----------
  9. 1 0 Producer 1 P002 299928364
  10. 1 0 Producer 1 P003 299954384
  11. 1 0 Producer 2 P002 300188788
  12. 1 0 Producer 2 P003 299951708
  13. 1 0 Consumer 1 P000 300005811
  14. 1 0 Consumer 1 P001 300005811
  15. 1 0 Consumer 2 P000 300005811
  16. 1 0 Consumer 2 P001 300005811
  17. 1 1 Producer 1 P000 1
  18. 1 1 Producer 1 P001 1
  19. 1 1 Producer 2 P000 1
  20. 1 1 Producer 2 P001 1
  21. 1 1 Consumer 1 QC 4
  22. 13 rows selected.

小結，Broadcast和Hash分發的陷阱

通過前一節和本節的例子

相關推薦

陳煥生：深入理解Oracle 的並行執行

Oracle並行執行是一種分而治之的方法。執行一個sql 時，分配多個並行程序同時執行資料掃描，連線以及聚合等操作，使用更多的資源，得到更快的sql 響應時間。並行執行是充分利用硬體資源，處理大量資料時的核心技術。 在本文中，在一個簡單的星型模型上，我會使用大量

深入理解Oracle表(5)：三大表連線方式詳解之Hash Join的定義，原理，演算法，成本，模式和點陣圖

 Hash Join只能用於相等連線，且只能在CBO優化器模式下。相對於nested loop join，hash join更適合處理大型結果集        Hash Join的執行計劃第1個是hash表(build table)，第2個探查表(probe table)，

深入理解Oracle 的並行執行

Oracle並行執行是一種分而治之的方法。執行一個sql 時，分配多個並行程序同時執行資料掃描，連線以及聚合等操作，使用更多的資源，得到更快的sql 響應時間。並行執行是充分利用硬體資源，處理大量資料時的核心技術。  在本文中，在一個簡單的星型模型上，我

鏈接：深入理解javascript構造函數和原型對象

原型對象 函數 href 深入理解java asc 構造 rip spa tar 鏈接：深入理解javascript構造函數和原型對象http://www.jb51.net/article/55539.htm 鏈接：深入理解javascript構造函數和原型對象

C中異步IO淺析之三：深入理解異步IO的基本數據結構

c 異步io libaio 一個函數庫或一段代碼的數據結構之間的關系，既展示了數據的行蹤，同時又隱含了函數的調用順序和使用方法。libaio內部的多個數據結構尤其如此，哪怕我們找不到文檔或者幫助手冊，只要深刻領悟頭文件中定義的數據結構及其內在聯系，再加一點代碼的驗證，就可以達到對libaio的A

轉：深入理解Java G1垃圾收集器

線程數 hot 原因 重要 特性 賦值 圖標 參數 堆內存 java垃圾收集器的歷史 第一階段，Serial（串行）收集器 在jdk1.3.1之前，java虛擬機僅僅能使用Serial收集器。 Serial收集器是一個單線程的收集器，但它的“單線程”的意義並不僅僅是說明它只

Android 異步消息處理機制前篇(二)：深入理解Message消息池

連接 guid ply 指針 cau ann 區別 就會 消息處理機制 版權聲明：本文出自汪磊的博客，轉載請務必註明出處。 上一篇中共同探討了ThreadLocal,這篇我們一起看下常提到的Message消息池到底是怎麽回事，廢話少說吧，進入正題。 對於稍有經驗的開發人員來

維加斯網投開戶教育部部長陳寶生：抓緊起草學前教育法

努力提高幼師、保教人員的待遇育頻TEL:13378795299育頻道3月16日訊 （記者 周繼鳳）十三屆全國人大一次會議記者會上，教育部部長陳寶生就學前教育問題答記者問。陳寶生部長提出了學前教育的七大問題，並回應在今年，將實行七大舉措改善學前教育，其中包括會同有關部門抓緊起草學前教育法。道3月16日訊 （記者

java基礎學習總結（十二）：深入理解java內部類

內部類 內部類也是語法糖，是因為它僅僅是一個編譯時的概念，outer.java裡面定義了一個內部類inner，一旦編譯成功，就會生成兩個完全不同的.class檔案了，分別是outer.class和outer$inner.class。所以內部類的名字完全可以和它的外部類名字相同。 內部類分為四

java基礎學習總結（九）：深入理解Java泛型

一、什麼是泛型         “泛型” 意味著編寫的程式碼可以被不同型別的物件所重用。泛型的提出是為了編寫重用性更好的程式碼。泛型的本質是引數化型別，也就是說所操作的資料型別被指定為一個引數。 比如常見的集合類 LinkedList: publi

安卓專案實戰之強大的網路請求框架okGo使用詳解（二）：深入理解Callback之自定義JsonCallback

前言 JSON是一種取代XML的資料結構,和xml相比,它更小巧但描述能力卻不差,由於它的小巧所以網路傳輸資料將減少更多流量從而加快了傳輸速度，目前客戶端伺服器返回的資料大多都是基於這種格式的，相應的我們瞭解的關於json的解析工具主要有兩個：Gson（Google官方出的）和fas

內存系列二：深入理解硬件原理

還要 傳輸 矩陣 bios 怎麽 線上 工程 什麽 所有 本篇文章承接上文繼續介紹DDR內存的硬件原理，包括如何尋址，時序和時延以及可以為提高內存的效能可以有哪些方法。 上次雖然解決了小張的問題，卻引發了他對內存原理的興趣。這不他又來找我了，說我還欠他一個解釋。這次我們約在

記憶體系列二：深入理解硬體原理

本篇文章承接上文繼續介紹DDR記憶體的硬體原理，包括如何定址，時序和時延以及可以為提高記憶體的效能可以有哪些方法。 上次雖然解決了小張的問題，卻引發了他對記憶體原理的興趣。這不他又來找我了，說我還欠他一個解釋。這次我們約在一個咖啡館見面，這次內容有點深入，我帶了些圖片，小張也點了一大杯美式，計劃大幹一

[轉]Java 併發：深入理解 ThreadLocal

版權宣告： 摘要： 　　ThreadLocal 又名執行緒區域性變數，是 Java 中一種較為特殊的執行緒繫結機制，用於保證變數在不同執行緒間的隔離性，以方便每個執行緒處理自己的狀態。進一步地，本文以ThreadLocal類的原始碼為切入點，深入分析了T

跟廠長學PHP7核心（八）：深入理解字串的實現

在前面大致預覽了常用變數的結構之後，我們今天來仔細的剖析一下字串的具體實現。 一、字串的結構 struct _zend_string { zend_refcounted_h gc; /* 字串類別及引用計數 */ zend_ulong h; /* 字

Nodejs探祕：深入理解單執行緒實現高併發原理

前言 從Node.js進入我們的視野時，我們所知道的它就由這些關鍵字組成 事件驅動、非阻塞I/O、高效、輕量，它在官網中也是這麼描述自己的: Node.js® is a JavaScript runtime built on Chrome’s V8 JavaScript e

java基礎：深入理解JDK動態代理

其他更多java基礎文章： java基礎學習(目錄) 經過上一節我們講了Class物件和反射機制，這節就來講一下反射機制在java中的主要應用——動態代理。在講動態代理之前，會先講一下代理模式和靜態代理。 一、代理模式 代理模式是常用的java設計模式，他的特徵是代理類與委託類有同樣的介面，代理類主

深入理解併發/並行，阻塞/非阻塞，同步/非同步 同步與阻塞，非同步與非阻塞的區別

同步與非同步是對應的，它們是執行緒之間的關係，兩個執行緒之間要麼是同步的，要麼是非同步的。阻塞與非阻塞是對同一個執行緒來說的，在某個時刻，執行緒要麼處於阻塞，要麼處於非阻塞。阻塞是使用同步機制的結果，非阻塞則是使用非同步機制的結果。 深入理解併發/並行，阻塞/非阻塞，同步/非同步 1. 阻塞，非

Java併發指南2：深入理解Java記憶體模型JMM

一：JMM基礎與happens-before 1併發程式設計模型的分類 1.1執行緒之間如何通訊及執行緒之間如何同步 1.11執行緒之間的通訊機制 通訊：執行緒之間以何種機制來交換資訊 通訊機制有兩種：共享記憶體和訊息傳遞。 共享記憶體併發模型 執行

第十五節：深入理解async和await的作用及各種適用場景和用法

一. 同步VS非同步 1.   同步 VS 非同步 VS 多執行緒 同步方法：呼叫時需要等待返回結果，才可以繼續往下執行業務 非同步方法：呼叫時無須等待返回結果，可以繼續往下執行業務 開啟新執行緒：在主執行緒之外開啟一個新的執行緒去執行業務 同步方法和非