• 首先紅色的生產者PX slave掃描hash_t3表，並對掃描的記錄按照HASH分發方式把相關記錄寫入table queue TQ10000
• 藍色的消費者PX slave從table queue TQ10000接收資料並構建hash table。
• 上面操作結束後，紅色的生產者繼續掃描hash_t1表，並對掃描的記錄按照HASH分發方式寫入table queue TQ10001
• 藍色的消費者PX slave從table queue TQ10001接收資料，並與上面的HASH TABLE做探測，但是結果並不能寫入table queue TQ10002，而是先暫時快取起來(hash join buffered的由來）
• 等HASH分發完成之後（也就是這兩組PX slave不活躍以後），然後由一組PX slave把結果集透過table queue TQ10002傳送給QC。

為什麼要這樣？貌似是沒有道理的。
這就是因為hash分發要求對hash join的右邊也要進行分發，分發操作涉及了2組PX slave程式，一組負責掃描，一組負責接收資料，也就是一組PX slave把掃描的資料寫入table queue，一組負責從table queue讀取資料，這個時候不能 再進行資料的分發操作，因為join的結果集不能寫入另一個table queue TQ10002。
如果結果集較大的話，這個可能在一定程度上會導致消耗很多臨時表空間，導致大量的磁碟讀寫IO，進而引起效能降低。
如果確實產生了這種情況，可以透過改用broadcast分發來避免出現這種情況，因為broadcast分發對於hash join的右邊並不需要進行分發

select /*+ parallel(6) pq_distribute(b broadcast none)*/ * from hash_t3 a ,hash_t1 b where a.id=b.id;

例如改成broadcast後，hash join buffered操作已經消失了。

布隆過濾

我們有必要介紹一下布隆過濾，它在11GR2之後版本的並行裡有非常大的作用。bloom filter並非Oracle的發明，bloom filter技術出現的時候Oracle軟體還未誕生，它在1970年由Burton H.Bloom開發出來，布隆過濾到什麼？
布隆過濾或者說布隆過濾器，是一種資料結構，它能夠快速的判斷一個資料是否屬於一個集合，hash join本身是非常消耗資源的，也是非常慢的，布隆過濾比hash join快很多。

關於布隆過濾的詳細介紹請參照：http://www.cnblogs.com/haippy/archive/2012/07/13/2590351.html

布隆過濾器基於一個有M位的陣列，例如上圖陣列的大小有18位，初始化的時候全部的值都為0，如果要理解布隆過濾是如何工作的，必須要知道在什麼情況下，這些標誌位需要置為1，上圖中{X，Y，Z}代表著一個集合，這個集合有3個值（元素），仔細觀察每一個值都延伸出了三個線，在這裡代表著每一個值都經過3個HASH函式計算，計算出來的值的範圍是從0-17（陣列的長度），例如，X經過3次HASH函式計算，值分別為：1，3，13，然後對應的標誌位被置為1，Y，Z同理把相應的標誌位置為1。經過一番HASH計算，{X，Y，Z}集合的所有元素都已經經過了HASH計算，對應的標誌位也都置為了1，然後我們再探測另一個集合，這裡另一個集合的元素為W，W同樣需要經過相同的3個HASH函式計算，並且檢測對應的位置是否為1，如果對應的位置都為一，那麼W可能（僅僅是可能）屬於這個集合，如果有任何的位置不為1，那麼這個W一定不屬於這個集合。由於布隆過濾並不對值進行精確的匹配（而HASH JOIN是需要精確匹配的）,因此可能會有一些不該屬於集合的值穿越了布隆過濾器。

布隆過濾器有如下特點：

• 構建布隆過濾陣列要求的記憶體非常小，經常可以完全放入在CPU的cache中。當然布隆過濾的陣列越大，布隆過濾誤判的可能性也就越小。
• 由於不需要精確匹配，因此布隆過濾的速度非常的快，但是有一些不該出現的值可能會穿越布隆過濾器。

PX Deq Credit: send blkd 與PX Deq Credit: need buffer

布隆過濾有啥用呢？也許你是一位有著豐富經驗的老DBA，那麼你對PX Deq Credit: send blkd 、PX Deq Credit: need buffer等待事件也許就比較熟悉。經過上面的介紹，我們已經具備了很多的知識，table queue，生產者消費者模型等等，一組消費者PX slave寫入table queue，另一組透過讀取table queue來獲取資料，完成程式間資料的傳遞，但是一定會出現一種情況，當一組生產者PX slave在往table queue中寫入資料的時候，發現table que中的記憶體已經滿了，沒有剩餘記憶體可以寫了，這種情況大部分時候都意味著消費者PX slave從table queue中消費資料過慢，過慢最大可能原因是由於消費者不得不把table queue中讀取到的資料溢位到磁碟，從記憶體讀取資料寫入磁碟是個很慢的操作，因此在這種情況下，就會遭遇PX Deq Credit: send blkd 、PX Deq Credit: need buffer等待，如何最佳化？這種情況下，布隆過濾就發揮了作用。
如果最佳化器認為表X返回1000條記錄，表Y需要掃描一億條記錄，但是經過HASH JOIN後，有90%都不需要返回，這種情況下使用布隆過濾在進行HASH分發前預HASH JON。這樣經過布隆過濾器，有大量的記錄就被布隆過濾器所淘汰，最後HASH JOIN右邊的結果集就變得非常小，也就讓HASH 分發的資料量變得非常的小，大大減少了出現PX Deq Credit: send blkd 、PX Deq Credit: need buffer的機率。如果不使用布隆過濾，程式不得不傳遞大量的資料給另一組程式，增加了記憶體，CPU，增加了兩組程式的程式間競爭。
不要期待布隆過濾是完美的，他能消除掉大部分的行，但是不是 所有的行，因此有一些不需要的資料會穿過布隆過濾器達到第二組程式。

並行度降級

無論你使用的是手工指定DOP，還是使用11G的AUTO DOP，執行時的DOP都有可能與你預期的不一樣：可能被降級。可能會有很多種原因導致並行被降低，例如，當前系統中可用的並行程式已經不能滿足需要的DOP，或者你已經使用了Oracle的資源管理器對並行度做了限制，等等。
監控並行度降低的最好工具是oracle 12.1版本的SQL MONITORING，例如：

點選後出現：

如果你不方便使用EMCC，也可以透過檢視觀察到並行度降級的情況，但是被降級的理由，暫時還沒有檢視反應（或者我還不知道，如果你知道請告訴我）

DEGREE 列為實際的並行度，REQ_DEGREE 為請求的並行度。
有一些手段可以避免並行度降級，例如如果使用的是ORACLE 11G版本，可以使用自動並行管理功能，然後結合在語句級指定並行度。因為自動並行度功能一單被開啟，並行語句排隊功能將被啟用，如果語句執行時發現沒有足夠的可用並行程式，那麼會排隊等待，直到有滿足目標的可用並行程式。

多個DFO 單元

一些命令可以有多個DFO單元，因為每個DFO單元最多可以使用2個PX slaves set，如果一個命令有多個DFO單元，那麼它就可以使用超過2個PX slaves set，可以在執行計劃裡看到是否使用了多個DFO單元：
select count() from (select /+ parallel(a 4) /count() from hash_t1 a
union
select /+ parallel(b 4) / count(*) from hash_t2 b)

行ID為6和12的行源兩處都有coordinator標識，這意味著這個命令使用了2個DFO單元。

透過SQL MONITORING也可以看到這個命令具有了2個並行組,理論上每個DFO單元之間可以同時進行並行操作，但是我們這個例子裡，兩個DFO單元之間的執行順序是，先執行DFO單元1，再執行DFO單元2，可以透過【時間表】列看到，第一個DFO單元先活躍，等結束後，第二個DFO單元開始活躍。
從上圖還可以看出，DFO單元2複用了DFO單元1的並行程式，沒有重新產生新的並行程式，從並行程式編號上可以看出這一點。SQL MONTIRONG是不是超級好用？

v$pq_sesstat檢視

透過查詢v$pq_sesstat檢視，可以知道語句執行時的DFO單元的數量（DFO Trees），並行集的個數（Slave Sets ），服務程式的個數（Server Threads），執行所採用的並行度（DOP）。如下：

寫到這裡文章已經有點長了，對於12C的新特性還少有涉及，對於並行執行傾斜的內容也還未涉及，對於布隆過濾的傳遞和高階知識也未涉及。對於這些內容，我會在下一篇進行介紹。