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

PX Deq: Execution Msg

該事件是並行查詢中的常見事件。當PQ slave程式在等待QC告訴它要做什麼的時候就會出現此事件(eg: when waiting to be told parse / execute / fetch etc..)

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

passes 程式在得到資訊之前迴圈輪轉等待的次數

該等待事件是一個空閒等待事件，當此等待事件出現,程式會持續等待並逐漸增加等待次數直到獲取資訊！

找到掛起的原因：

p1 的值表示正在等待資訊的程式！

轉摘

在主程式給parallel後,子程式被分發到了另一個節點,可能在長時間的執行過程中,某些子程式找不到上級程式,而上級程式需要等待所有子程式返回結果,於是出現等待,造成程式掛起。但事實上並非長期的PX Deq: Execute Reply等待都意味著程式被掛起,比如有些很差的執行計劃導致了長期的執行,無法判斷是掛起還是後臺正在執行。此時,我檢查的方法:

kl@k01> SELECT AUDSID FROM GV$SESSION WHERE EVENT LIKE 'PX%';

AUDSID

----------

72691033

72700075

72691033

kl@k01> SELECT INST_ID,SID, SERIAL#, EVENT FROM GV$SESSION WHERE AUDSID='72691033'

INST_ID SID SERIAL# EVENT

---------- ---------- ---------- ------------------------------

1 2388 1464 PX Deq: Execution Msg

1 2396 2107 db file parallel read

1 2414 2023 PX Deq: Table Q Normal

1 4907 5768 PX Deq: Execution Msg

1 4937 2742 PX Deq: Table Q Normal

---如果不是所有的Session都是PX Deq: Execution Reply,說明你的程式沒有掛起,不必把table的parallel改回1,或者disable parallel query/dml/ddl ...

參考：

http://hi.baidu.com/klkl1110/blog/item/037638168453b5064b90a700.html

http://www.oracleblog.cn/working-case/sql-wait-long-time-on-px-deq-execute-reply/?m=20070710

【Oracle】並行等待之PX Deq: Execution Msg

相關文章