【Oracle】并行等待之PX Deq: Table Q Normal

本系列文章将会介绍在并行操作过程中 slave 进程和 QC 进程经常遇到的等待事件！ Waiting Processes:Slave 在并行执行环境中我们建立建立producer consumer 模型：  处理数据(比如 从磁盘获取数据并做join 连接)的slave 集叫做producer slave ；另外一些等待获取处理结果数据的slave 称为consumer slave 。等待事件 "PX Deq: Table Q Normal" 意味着消费者slave进程等待生产者slave进程传递数据，然后他们(消费者)进程才能进行工作！  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 ); 如果P1的值为空，则意味slave 不需要等待任何进程 比如p1的值为268501004，则上面的sql会返回： Instance = 1 Sender = P012 等待时间：空闲等待事件 这虽然是一个空闲等待事件，但是较长的等待时间意味着生产者slave 没有足够快的产生数据或者slave 集之间的通信方面存在问题！ 解决办法：    Investigate the slaves in  other slave set why they are not able to send the data faster.
为什么用 PostgreSQL 绑定变量 没有 Oracle pin S 等待问题 早上看到盖国强老师在朋友圈里分享了一篇关于软解析带来的Pin S等待的问题。有感而发，跟大家聊一聊为什么PostgreSQL不存在这个问题。 Oracle 在Oracle中多个会话高并发的执行同一条SQL，如果使用了绑定变量的话，会产生pin s的等待事件。原因如下（取自互联网http://