这个latch Child parallel query alloc buffer 也就是在进行Px msg pool 内存分配的时候需要获得的，当内存分配完毕之后latch会立刻
释放，通常情况下，Oracle 对于Latch的申请和释放是非常之快的。很明显这里这个进程由于申请内存失败，导致latch也没有释放，还阻塞
了一堆的会话。

由于朋友这里没有其他的信息，所以很难准确的定位到是不是碎片或者其他的问题。但是从trace 里面也不难发现一些信息。前面提到进程
申请内存，势必就要看看下这个会话是什么操作了，不看不知道，一看吓一跳，如下：

MERGE INTO xx.xxxx_A A
USING (SELECT /*+ parallel(a,512) parallel(b,8)  */
        :B2 STATIS_MONTH,
        NVL(B.PROV_ID, '000') PROV_ID,
        COUNT(DISTINCT A.SERV_NUM) CNT
         FROM (SELECT DISTINCT SERV_NUM
                 FROM xxx.TDW_XXXXX_MIGU_MEMBER_M A
                WHERE STATIS_MONTH = :B1
                  AND MEMBER_LVL = '1'
                  AND MEMBER_STAT IN ('1', '0')
                  AND EXISTS (SELECT /*+ parallel(b,64)*/
                        1
                         FROM xxx.TKR_DEV_XXXXX_CORE_M B
                        WHERE A.SERV_NUM = B.SERV_NUM)) A,
              xxx.VDW_NUMBER_SEGMENT B
        WHERE SUBSTR(A.SERV_NUM, 1, 7) = B.SEGMENT(+)
        GROUP BY B.PROV_ID) B
ON (A.STATIS_MONTH = B.STATIS_MONTH AND A.PROV_ID = B.PROV_ID)
WHEN MATCHED THEN
  UPxxTE SET CORE_NRML = CNT

大家可以看到，这个sql居然开了512个并行，如果把几个表的并行都加起来，高达584个。问题应用这里还不止这一个SQL。

对于并行查询，我们知道，即使你的并行度设置的再高，也不一定能用这么多，因为这是受限制数据库参数的。不过，悲剧的是，
他这里默认参数都是比较大的。cpu_count=114，默认的dop都高达228。parallel_max_server更是高达好几千了。

还有一点，他的参数parallel_force_local是ture，这也导致parallel进程只能在单个实例进行分配。

其实上述信息都不是重要的，更重要也是更致命的一点的是，并行查询使用的Px msg pool居然从shared pool了进行分配了。

我看信息，他这里的large pool设置高达10gb啊，其实是完全没用派上用场。

对于Px msg pool，如果你的数据库PARALLEL_MIN_SERVERS比较大（这里就是比较大），那么当数据库启动时候，可能Px msg pool
就会消耗不少的内存的。

对于Parallel操作的内存消耗Px memory，可以从large pool分配，也可以从shared pool进行分配。这里需要注意，即使你设置了
large pool，如果不满足下面的条件，那么Px memory仍然会从shared pool去分配。

1) parallel_automatic_tuning 参数设置为auto
2) _PX_use_large_pool 隐含参数设置为true
3) 使用ASMM ，即使设置了sga_target 或 memory_target.

很遗憾的是，他这里3点都不满足。