遇到大量的PX Deq等待事件

风三

环境是RHEL 5.5 10204 64bit RAC
awr做了一个小时，top 5如下：

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
PX Deq: reap credit	14,704,693	55,202	4	61.3	Other
PX Deq Credit: send blkd	982,425	26,838	27	29.8	Other
IPC send completion sync	202,043	11,544	57	12.8	Other
latch free	171,804	9,547	56	10.6	Other
CPU time		4,037		4.5

一开始的load profile如下：

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	30087	23-Dec-11 13:00:00	304	1.7
End Snap:	30088	23-Dec-11 14:00:07	366	1.6
Elapsed:		60.11 (mins)
DB Time:		1,500.70 (mins)

查了一下所有应用的表和索引degree都为1，数据库相关的并行参数如下：
SQL> show parameter parallel
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fast_start_parallel_rollback         string      LOW
parallel_adaptive_multi_user         boolean     TRUE
parallel_automatic_tuning            boolean     FALSE
parallel_execution_message_size      integer     2152
parallel_instance_group              string
parallel_max_servers                 integer     256
parallel_min_percent                 integer     0
parallel_min_servers                 integer     0
parallel_server                      boolean     TRUE
parallel_server_instances            integer     2
parallel_threads_per_cpu             integer     2
recovery_parallelism                 integer     0

ps -ef|grep ora_p 有260个进程。
但另外一套相同环境的rac，parallel_max_servers参数为400，却并没有这么多后台进程。请教一下处理问题的方向，谢谢了。

Maclean Liu(刘相兵

查了一下所有应用的表和索引degree都为1 => 并不代表没有并行 QUERY、DML or DDL


上传你收集到的这个AWR

风三

做了两个awr，30087_30088那个更明显

几番风雨

么钱。。。。。。。。。。。。

几番风雨

原帖由 风三 于 2011-12-26 11:12 发表 做了两个awr，30087_30088那个更明显

貌似可以参考这篇文章

http://www.eygle.com/archives/2009/09/px_deq_reap_credit.html

Maclean Liu(刘相兵

PX Deq: reap credit
PX Deq Credit: send blkd
IPC send completion sync
latch free  ==> query server freelists  by  kxfpobrmf =>parallel query statistics


这4个 主要等待事件都指向 系统存在频繁的并行查询


而占用主要DB TIME的SQL是：

SQL ordered by Elapsed Time

    Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
    % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

Elapsed Time (s)        CPU Time (s)        Executions         Elap per Exec (s)         % Total DB Time        SQL Id        SQL Module        SQL Text
14,451         419         68         212.52         16.05         7x39qgz590xqz                   select tp.CONTEXTID as ...
13,073         389         68         192.25         14.52         gs0mw9thtjk48                   select detail.orderid a...
9,904         310         68         145.65         11.00         1j4a0w8r2rkdx                   select tc.CONTEXTID as ...

看了下 7x39qgz590xqz gs0mw9thtjk48
1j4a0w8r2rkdx

三个sql均没有parallel hint ，按照lz的说话这些对象的degree也都是1 ，所以排除因为 hint和degree属性引发的并行查询




action plan:




1. 通过ASH  确认是到底哪些SQL语句引起了PX Deq类型的等待。，是否是7x39qgz590xqz gs0mw9thtjk48
1j4a0w8r2rkdx这些


2. 若能重现该现象，那么使用<脚本:监控并行进程状态> http://www.oracledatabase12g.com ... rallel-queries.html   监控并行查询 获得更多信息


3. metalink note Why Did My Query Go Parallel? [ID 196938.1] 介绍了普通查询并行化的几种可能引用如下：

Applies to:
Oracle Server - Enterprise Edition - Version: 8.1.7.4 and later   [Release: 8.1.7 and later ]
Oracle Server - Personal Edition - Version: 8.1.7.4 and later    [Release: 8.1.7 and later]
Information in this document applies to any platform.
Purpose
This article outlines things that will force the use of parallel query.
Scope and Application
DBA's & Support Analysts
Why Did My Query Go Parallel?

The following are features that will make the optimizer consider the use of a parallel plan for a query:

    Parallel hints i.e. /*+ PARALLEL(emp,5) */ ?
    Parallel session setting e.g.:

    PARAMETER:parallel_automatic_tuning
    PARAMETER:parallel_adaptive_multi_user

    Setting a degree of parallel and/or the number of instances on a table or index in a query

The affect of setting a degree of parallelism on an index has changed. Prior to 8i this would have had no affect. Post 8i a parallel plan will be investigated. If degree is set ( to an integer value > 1 or to 'DEFAULT' ) on an object then this will mean a parallel plan is considered. Remember that the optimizer works on a cost basis so just because a parallel plan may be considered, does not mean that it will be chosen. Since 8i we have changed the syntax for the setting of degree of parallelism See Note 260845.1 Old and new Syntax for setting Degree of Parallelism .

Examples

The following examples use EMP which has no parallel degree or instances set. Choice of a parallel plan can be seen from the autotrace output (set autot trace explain).
SQL> select degree, instances from user_tables where table_name= 'EMP';

DEGREE INSTANCES
---------- ----------
1               1

Unhinted Query:
SQL> select * from emp;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=14 Bytes=448)
1 0 TABLE ACCESS (FULL) OF 'EMP' (Cost=1 Card=14 Bytes=448)


Parallel Degree hint or setting degree on the table:
         
SQL> select /*+ parallel(emp,5) */ * from emp;

OR

SQL> alter table emp parallel(degree 5);

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=14 Bytes=448)
1 0 TABLE ACCESS* (FULL) OF 'EMP' (Cost=1 Card=14 Bytes=448) :Q492000

1 PARALLEL_TO_SERIAL SELECT /*+ NO_EXPAND ROWID(A1) */ A1."EMPNO"
,A1."ENAME",A1."JOB",A1."MGR",A1."HI

Parallel Instances hint or instances set in the object:
SQL> select /*+ parallel(emp,1,5) */ * from emp;

OR

SQL> alter table emp parallel(degree 1 instances 5);

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=14 Bytes=448)
1 0 TABLE ACCESS* (FULL) OF 'EMP' (Cost=1 Card=14 Bytes=448) :Q494000

1 PARALLEL_TO_SERIAL SELECT /*+ NO_EXPAND ROWID(A1) */ A1."EMPNO"
,A1."ENAME",A1."JOB",A1."MGR",A1."HI


NOTE that setting degree or instances will override any RULE hints:

      

      
SQL> select /*+ rule */ * from emp;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: RULE (Cost=1 Card=14 Bytes=448)
1 0 TABLE ACCESS* (FULL) OF 'EMP' (Cost=1 Card=14 Bytes=448) :Q500000

1 PARALLEL_TO_SERIAL SELECT /*+ NO_EXPAND ROWID(A1) */ A1."EMPNO"
,A1."ENAME",A1."JOB",A1."MGR",A1."HI

[ 本帖最后由 maclean 于 2011-12-26 20:05 编辑 ]

kevinlin.ora

建议上传1号节点的AWR，可能并行SQL是从1号节点发起的。

风三

感觉区别不大。index上的instances设置为default是什么意思？文档里没找到。
另外latch free主要是query server freelists，应该是并行查询太多的缘故吧。

风三

发现有张关键表（分区）的degree和instances都是1，索引上的degree是1，但instances是default。然后看了下sql的执行计划（几乎每个sql都用用到这张表），索引扫描的时候是并行的，不走索引就没有并行，是否可以说明是这张表上索引的设置引起的。
然后如果关掉并行的话，是否可能会影响sql的执行效率呢？
请教，谢谢了。

Liu Maclean(刘相兵

1. 并行可以一定程度上加速大数据量的查询工作， 但是若有频繁的并行查询 则可能影响 系统原有的性能

2. 就AWR来看并行等待 已经极大程度地成为该系统的 性能瓶颈

风三

好。先去测试下，然后尝试下改改看。谢谢两位。：）

风三

改完了没问题了，没再出现并行相关的等待事件，同时后台的oracle进程也少了很多。
按照文档里的说法，default的并行度=cpu_count*threads_per_cpu，那就是48*2=96个。难怪。