可参考 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 数目不足或者 系统中运行的 进程太多导致。可考虑 减小并行度。