等待事件PX Deq: Execute Reply

这是一个统计库。
操作系统为aix 5.3,数据库版本为10.2.0.4 RAC
用户反映数据库查询一个视图的时候长时间牌执行状态，不出数据。
赶到现场一看，这个视图的名字是SYS.DBA_PENDING_TRANSACTIONS
用select 1 from SYS.DBA_PENDING_TRANSACTIONS where rownum < 6;
等了一分钟没有出数据。

看了一下等待事件：PX Deq: Execute Reply

这是我第一次遇到这个等待，上网一查，原来与并行执行有关。
在实例二上查旬v$px_session结果如下：
select * from v$px_session
saddr                   sid           serial#          qcsid          qcinst_id
--------                -------      -------------     -----------     --------------
c000cbaadv10      3205          6                3265                1
c000cbetdv67l      3265          89              3265               
从上面的信息我估计应该是在实例1上做了一个并行查询，子查询被分配到实例二上，但实例二长时间没有返回结果，导到问题的发生。

用sid=3265到实例1上查询v$session视图的sql_id字段，结合v$sqlarea,得到当前正在执行的sql:
SELECT formatid, globalid, branchid
FROM SYS.DBA_PENDING_TRANSACTIONS
ORDER BY formatid, globalid, branchid
与用户咨询，这个会话可以杀掉
与于是实例一上将sid=3265的会话干掉了。
本以为问题能解决，结果发现依然照旧，再查询，原来实例一上的会话已经漂到了实例二上去了。

后来考虑到时间紧，于是就把两个实例都重启了。
重启后，问题照旧。还是那个视图，还是同样的等待，处了sid不一样了其它的都一样。

最后实在没有别的办法了，把parallal_max_servers 参数设为了0,然后再重启数据库，问题才解决。经常观察，问题没有重现。

但是，设位适当的并行能提高查询效率。禁用并行并非长久之计。这个问题正常来讲应该如何解决

 

 

PX Deq: Execute Reply，这个事件是一个空闲事件，是QC等待PX slaves产生的。所以问题不是在PX Deq: Execute Reply，而是在PX slaves，也就是说可能存在其他的等待导致这个等待。看看你的top5，分析是否还存在其他的等待事件影响了PX slaves

 

DBA_PENDING_TRANSACTIONS查询不了，一般是分布式事务lock导致的

 

分布式事务一般查询dba_2pc_pending,以后也看看这个dba_pending_transactions

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13165828/viewspace-608920/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13165828/viewspace-608920/