本系列文章将会介绍在并行操作过程中 slave 进程和 QC 进程经常遇到的等待事件！
PX Deq: Join ACK 等待
Waiting Process: QC
当我们执行并行语句的时候,查询协调器会根据并行度来创建slave 集合。协调进程首先会发送给每一个将要被使用的slaves一个join messages ,然后等待slave 进程返回 join 确认信息。如果并行操作需要两个slave 集合此过程会重复一遍！
等待时间：此等待事件是一个非空闲等待事件.
当PARALLEL_AUTOMATIC_TUNING = FALSE 时,slave加入一个slave 集合,它从shared pool中获取内存;
当PARALLEL_AUTOMATIC_TUNING = TRUE 时,它从large pool 中获取内存. 并行操作需要这些内存进程 slave to slave 或者slave to QC 之间的通信！此等待事件意味着QC 向slave 发送一个信息并等待分配给slave 内存然后返回一个确认信息给QC。
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
Systemwide Waits:
发现此等待事件时应该在sql 进程层面进行调查。
可能的原因是：
有人在OS 层面终止了 slave 进程或者slave 进程异常中断。在PMON进程还没有处理slave的内部结构之前QC还以为他们还活着。当一个QC 尝试着将一个它发送消息的
slave加入slave 集合中时,但是QC并没有得到响应。应该检查是否有人kill 了一个空闲的slave进程。
另外一个原因是SGA空间耗尽,此时slave进程无法获取空间来建立向QC发送确认信息的通信通道,强制终止slave以便QC在PMON进程对slave进程进行清理的时候获得slave已经终止的通知。