PX Deq：Join ACK等待事件分析

使用oracle过程中偶然间发现有很多的PX Deq:Join ACK等待事件，对事件进行跟踪发现数据库的内存消耗很高，因系统正处于高峰运行期，根据之前的信息可以确认系统并无大的问题，进一步的session跟踪后发现是个并行执行的查询语句（系统中很少见的），对此产生了怀疑，经过分析该语句要取回大量的数据，已经执行很长时间，根本无法满足需求，实在没有更好的办法了，直接kill掉了相应进程，再次观察系统，等待事件消失。

以下是个人与查找到的相关文件的分析内容，到现在该事件并没有再次产生大量等待。

 

概念与原理：
当以并行方式执行查询语句时，Query Coordinator首先会建立slave sets，QC首先给建立好的sets的每个slave发出join messages，然后等待slave返回acknowledgement 信息。如果并行操作需要多个slave set，前面的过程会不断的重复。

ACK=acknowledgement 确认

等待事件说明：

当一个slave 加入到了slave set中，就需要分配内存用于执行，PARALLEL_AUTOMATIC_TUNING=FALSE时需要从shared pool中分配内存；PARALLEL_AUTOMATIC_TUNING=TRUE时，需要冲large pool中分配。所分配到的内存用于slave与slave之间，slave与QC之间两种通信使用。

原因与解决方法：

可能的根本原因：
在OS级别上人为的kill掉了PQ slave进程或者这些进程自动死亡。在PMON进程没有清除这些internal strutures之前，一个新的QC将会假定他们还是活动的。根据正常机制，新的QC将试图去get 那些slaves，以使他们join 到slave set中，但是并没有返回acknowledge信息。进而发生了Join ACK等待事件。
解决方法：去比较V$PX_PROCESS和操作系统上启动的PQ slaves的名字，他们是否一致，在操作系统上那些是不存在的（也就是被人为杀死或者自动死亡的）。

另外一个根本原因：
Oracle的SGA消耗过多，基本耗尽，然后slave因没有分配到足够的内存，就不能建立信息的反馈通道，也就不能将join message的ACK 信息返回给QC，进而也就强制终止了这些slaves。

注明：该等待事件基本上没有完好的解决方法，需要等待Oracle系统自动去清除那些killed掉或者自动死亡的slaves。然后开始新的机制。