PX Deq: reap credit & GV$SESSION
来源:互联网 发布:淘宝售后率对店铺影响 编辑:程序博客网 时间:2024/04/19 12:36
在一个4节点的rac中查询全局视图时GV$SESSION时,总能出现三个相同的等待事件PX Deq: reap credit。
在Metalink的ID 250947.1文章中记录了这个等待事件。
This wait event indicates that we are doing a non-blocking test to see if any channel has returned a message.
We should see that although there is a high number of these events, the time accumulated to it should be zero
(or really low).
Wait Time:
This wait event indicates that we are doing a non-blocking test to see if any channel has returned a message.
Systemwide Waits:
You normally do not see a high wait on this event system wide. The wait should be investigated at the query level than at the system level.
Reducing Waits / Wait times:
There is no general advice to reduce the waitime for this event.
Depending on which process is doing this it could indicate that either the consumers are starved for data (IO bound perhaps) or the producers are waiting on the consumers to "return" the flow control credit (consumers may be compute or IO bound). You should investigate Query plans, check for data skew, IO contention (table or tmp segment) etc. , to get a deeper understanding of the symptoms.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
SQL> SELECT S.INST_ID FROM GV$SESSION S GROUP BY s.inst_id ;
INST_ID
----------
1
2
4
3
SQL> SELECT Instance_number FROM V$INSTANCE;
INSTANCE_NUMBER
-------------------------
1
当前在1节点上,这个等待事件并没有在1节点上产生。
SQL> col event for a20;
SQL> SELECT S.INST_ID,
2 S.EVENT,
3 S.SQL_ADDRESS,
4 S.SQL_HASH_VALUE,
5 S.SQL_ID
6 FROM GV$SESSION S
7 WHERE S.USERNAME IS NOT NULL
8 AND WAIT_CLASS != 'Idle'
9 ORDER BY s.INST_ID;
INST_ID EVENT SQL_ADDRESS SQL_HASH_VALUE SQL_ID
------------- -------------------- ------------------------ ---------------------- -------------------
2 PX Deq: reap credit 0000000252531DD0 1779404760 23d8ba9p0z3ys
3 PX Deq: reap credit 0000000250B3AC88 1779404760 23d8ba9p0z3ys
4 PX Deq: reap credit 0000000250256420 1779404760 23d8ba9p0z3ys
在2节点上时,这个等待事件在其它的三个节点上发生。
SQL> SELECT Instance_number FROM V$INSTANCE;
INSTANCE_NUMBER
---------------
2
SQL> SELECT S.INST_ID,
2 S.EVENT,
3 S.SQL_ADDRESS,
4 S.SQL_HASH_VALUE,
5 S.SQL_ID
6 FROM GV$SESSION S
7 WHERE S.USERNAME IS NOT NULL
8 AND WAIT_CLASS != 'Idle'
9 ORDER BY s.INST_ID;
INST_ID EVENT SQL_ADDRESS SQL_HASH_VALUE SQL_ID
---------- -------------------- ---------------- -------------- -------------
1 PX Deq: reap credit 00000001A6FD42D8 827254137 6nw92awsnxtbt
3 PX Deq: reap credit 0000000233778B80 827254137 6nw92awsnxtbt
4 PX Deq: reap credit 0000000211147638 827254137 6nw92awsnxtbt
这个等待事件一般可以忽略,但也有例外情况。
见:http://www.eygle.com/archives/2009/09/px_deq_reap_credit.html
频繁查询个oracle内部的视图都会引起数据库问题,看来在生产库上干啥都要小心啊!!!!
- PX Deq: reap credit & GV$SESSION
- 遇到PX Deq: reap credit等待事件
- 'Px Deq Credit: Send Blkd
- PX Deq Credit:send blkd(待验证)
- PX Deq Credit: send blkd 等待事件
- 等待时间 PX Deq Credit: need buffer 和 PX Deq Credit: send blkd
- oracle wait event:PX Deq Credit: send blkd
- 2013-03-13等待事件PX Deq Credit: send blkd
- AWR实战分析之---- PX Deq Credit: send blkd
- PX Deq: Execution Msg,PX Deq: Execute Reply等待事件
- PX Deq: Table Q Close
- 10g RAC在ASM实例下查询gv$session,会报错ORA-12850;11g RAC中查询正常!!!
- You reap what you sow
- GV事件全过程
- 反射绑定GV
- GV导出EXCEL,Word
- v$和gv$
- v$和gv$来源
- JDBC中驱动加载的过程分析(下)
- 让百度能经常刷新网站快照的方法
- JAVA String Pool
- 正则应用之--日期正则表达式
- cpu技术
- PX Deq: reap credit & GV$SESSION
- 深度剖析宽带路由器频繁死机掉线的原因
- 最小重量机器设计问题 5_1 6_4
- 90后黑客班级被解散,劫持网站发泄不满
- 关闭VS警告 warning C4996
- 数据挖掘SPSS Clementine 12.0.3 多国语言(含中文)破解版
- 第一次用writer写博客,挺方便的,呵呵
- SQLite3创建数据库的方法
- csdn论坛最近又有人灌水