本系列文章將會介紹在並行操作過程中 slave 程式和 QC 程式經常遇到的等待事件！

PX Deq: Join ACK 等待

Waiting Process: QC

當我們執行並行語句的時候,查詢協調器會根據並行度來建立slave 集合。協調程式首先會傳送給每一個將要被使用的slaves一個join messages ,然後等待slave 程式返回 join 確認資訊。如果並行操作需要兩個slave 集合此過程會重複一遍！

等待時間：此等待事件是一個非空閒等待事件.

當PARALLEL_AUTOMATIC_TUNING = FALSE 時,slave加入一個slave 集合,它從shared pool中獲取記憶體;

當PARALLEL_AUTOMATIC_TUNING = TRUE 時,它從large pool 中獲取記憶體. 並行操作需要這些記憶體程式 slave to slave 或者slave to QC 之間的通訊！此等待事件意味著QC 向slave 傳送一個資訊並等待分配給slave 記憶體然後返回一個確認資訊給QC。

v$session_wait 中該等待事件對應的引數：

P1 = sleeptime/senderid

P2 = passes

P3 = not used

sleeptime/senderid

我們可以使用如下語句獲取相關的資訊：

set SERVEROUTPUT on

undef p1

declare

inst varchar(20);

sender varchar(20);

begin

select bitand(&&p1, 16711680) - 65535 as SNDRINST,

decode(bitand(&&p1, 65535),65535, 'QC', 'P'||to_char(bitand(&&p1, 65535),'fm000') ) as SNDR

into inst , sender

from dual

where bitand(&&p1, 268435456) = 268435456;

dbms_output.put_line('Instance = '||inst);

dbms_output.put_line('Sender = '||sender );

end;

/

如果P1的值為空，則意味slave 不需要等待任何程式

比如p1的值為268501004，則上面的sql會返回：

Instance = 1

Sender = P012

Systemwide Waits:

發現此等待事件時應該在sql 程式層面進行調查。

可能的原因是：

有人在OS 層面終止了 slave 程式或者slave 程式異常中斷。在PMON程式還沒有處理slave的內部結構之前QC還以為他們還活著。當一個QC 嘗試著將一個它傳送訊息的

slave加入slave 集合中時,但是QC並沒有得到響應。應該檢查是否有人kill 了一個空閒的slave程式。

另外一個原因是SGA空間耗盡,此時slave程式無法獲取空間來建立向QC傳送確認資訊的通訊通道,強制終止slave以便QC在PMON程式對slave程式進行清理的時候獲得slave已經終止的通知。

【Oracle】並行等待之PX Deq: Join ACK

相關文章