本系列文章将会介绍在并行操作过程中 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

72691033

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