答案 例如 mos 數據 eve event select lec sleep

可參考 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 數目不足或者 系統中運行的 進程太多導致。可考慮 減小並行度。

PX Deq: Execution Msg 等待事件