PX Deq: Execution Msg 等待事件

可参考 MOS文档：

WAITEVENT: "PX Deq Credit: send blkd" (Doc ID 271767.1)

P1 = sleeptime/senderid
   P2 = passes
   P3 = qref

这是一个 IDLE wait event，需要查看 谁在等待(也就是那个 sender)：

例如：

在某个 Slave 进程的 trace 文件中，出现如下信息：

WAIT #139280095023008: nam='PX Deq: reap credit' ela= 5 p1=0 p2=0 p3=0 obj#=-1 tim=1022377594644
WAIT #139280095023008: nam='PX Deq: reap credit' ela= 4 p1=0 p2=0 p3=0 obj#=-1 tim=1022377595160
WAIT #139280095023008: nam='PX Deq: Execution Msg' ela= 513 sleeptime/senderid=268632063 passes=1 p3=21463455416 obj#=-1 tim=1022455595161

通过 tkprof 整形后出现了这样的信息：

=====================================================================================
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait  Total Waited
----------------------------------------   Waited  ----------  ------------
...

PX Deq: reap credit                           271        0.00          0.00
PX Deq: Execution Msg                          10        0.75          3.83
IPC send completion sync                        2        0.00          0.00
PX Deq Credit: send blkd                      102       32.63         94.44
PX Deq Credit: need buffer                      8        0.47          1.78
...
=====================================================================================
 
表明等待 PX Deq Credit: send blkd 事件，共等待了 94.44 秒。

可以执行如下的脚本：

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值，给出上面的sleeptime/senderid：268632063

经过计算后，得出答案：

Instance = 65537
Sender = QC

而且在任何一台运行Oracle 的机器上都如此。

这表明 ：
作为 Coordinator 的 Process 在获取 Slave 进程的数据时，反应太慢了，
导致某些 Slave进行因为 Queue 满而不得不等待，进而拖慢了整个并行执行的速度。

这常常是由于 CPU 数目不足或者 系统中运行的 进程太多导致。可考虑 减小并行度。