PX Deq Credit: send blkd wait event

Hi all,
I'm working on a performance issue for an Oracle 10.2.0.5 DB under HP UX.
While taking a look at the AWR I can see the following in the Top 5 Timed Events section:
The first is:
PX Deq Credit: send blkd
I checked and tables and indexes are not in parallel, may be the use queries with PARALLEL hint.
In Time Model Statistics setion, the first is sql execute elapsed time (95% of db time)
Is "PX Deq Credit: send blkd" a problem?
I mean, is the DB waiting for that or it's just an idle time and I shouldn't worry about that.
in wait classs, Other is 94% of db time.
Thanks in advance.
Edited by: Diego on 20-dic-2011 6:35

Hi jgarry,
How can I check how many slaves there are?
This is the output of the TOP command:
User CPU % Thrd Disk Memory Block
Process Name PID Name (1600% max) Cnt IOrate RSS/VSS On
ora_s000_dbs 23134 oracle 56.7 1 15.2 413.8mb 427.6mb SLEEP
ora_p007_dbs 23239 oracle 12.1 1 0.0 399.3mb 413.0mb SLEEP
ora_p009_dbs 23243 oracle 11.9 1 0.0 399.3mb 413.0mb SLEEP
ora_p010_dbs 23245 oracle 11.9 1 0.0 399.3mb 413.0mb SLEEP
ora_p017_dbs 23259 oracle 11.7 1 0.0 399.3mb 413.0mb SLEEP
ora_p013_dbs 23251 oracle 11.7 1 0.0 399.3mb 413.0mb SLEEP
ora_p011_dbs 23247 oracle 11.7 1 0.0 399.3mb 413.0mb SLEEP
ora_p002_dbs 23229 oracle 11.5 1 0.0 399.3mb 413.0mb SLEEP
ora_p003_dbs 23231 oracle 11.5 1 0.0 399.3mb 413.0mb SLEEP
ora_p008_dbs 23241 oracle 11.5 1 0.0 399.3mb 413.0mb SLEEP
ora_p005_dbs 23235 oracle 11.5 1 0.0 399.3mb 413.0mb SLEEP
ora_p015_dbs 23255 oracle 11.3 1 0.0 399.3mb 413.0mb SLEEP
ora_p006_dbs 23237 oracle 11.3 1 0.0 399.3mb 413.0mb SLEEP
ora_p012_dbs 23249 oracle 11.1 1 0.0 399.3mb 413.0mb SLEEP
ora_p001_dbs 23227 oracle 11.1 1 0.0 399.4mb 413.1mb SLEEP
ora_p016_dbs 23257 oracle 11.1 1 0.0 399.3mb 413.0mb SLEEP
ora_p019_dbs 23263 oracle 10.9 1 0.0 399.3mb 413.0mb SLEEP
ora_p014_dbs 23253 oracle 10.9 1 0.0 399.3mb 413.0mb SLEEP
ora_p018_dbs 23261 oracle 10.9 1 0.0 399.3mb 413.0mb SLEEP
ora_p004_dbs 23233 oracle 10.9 1 0.0 399.3mb 413.0mb SLEEP
ora_p023_dbs 23271 oracle 10.7 1 0.0 399.3mb 413.0mb SLEEP
ora_p000_dbs 23225 oracle 10.5 1 0.0 399.4mb 413.1mb SLEEP
ora_p020_dbs 23265 oracle 10.5 1 0.0 399.3mb 413.0mb SLEEP
ora_p025_dbs 23275 oracle 10.5 1 0.0 399.3mb 413.0mb SLEEP
ora_p022_dbs 23269 oracle 10.3 1 0.0 399.3mb 413.0mb SLEEP
ora_p028_dbs 23281 oracle 10.3 1 0.0 399.3mb 413.0mb SLEEP
ora_p021_dbs 23267 oracle 10.1 1 0.0 399.3mb 413.0mb SLEEP
ora_p029_dbs 23283 oracle 10.1 1 0.0 399.3mb 413.0mb SLEEP
ora_p024_dbs 23273 oracle 10.1 1 0.0 399.3mb 413.0mb SLEEP
ora_p027_dbs 23279 oracle 9.9 1 0.0 399.3mb 413.0mb SLEEP
ora_p026_dbs 23277 oracle 9.7 1 0.0 399.3mb 413.0mb SLE
What is ora_s000_dbs ? it uses more than 50% of CPU.
Could the problem be that there are too many slaves?
How Can I know how many there are and what can I do to reduce them ?
I think The more CPU Oracle has, the more slaves/threads are fired.
Thanks a lot.

Similar Messages

"PX Deq Credit: send blkd" wait event as pink line on EM

Hi,
We have waits "Other" and see pink lines on EM on a particular query.
Wait type is "PX Deq Credit: send blkd".
After i checked this wait type on google, i learned that this wait happens because of parallel queries.
My question is, we have a lot of queries in our DB but why we see this event type only when selecting from a materialized view? This mv has just 19.000 rows and that is so small when comparing to 100G tables in our 2.5TB db.
What could be the another reason to this pink lines? Do materialized views cause such a thing?
Thanks in advance,

KAYSERI wrote:
After i checked this wait type on google, i learned that this wait happens because of parallel queries.
My question is, we have a lot of queries in our DB but why we see this event type only when selecting from a materialized view? This mv has just 19.000 rows and that is so small when comparing to 100G tables in our 2.5TB db.
What could be the another reason to this pink lines? Do materialized views cause such a thing?For comments about whether the event is idle or not, here's something I wrote a couple of years ago on this forum:
Re: PX Deq Credit: send blkd At AWR "Top 5 Timed Events"
When you are "selecting from a materialized view" is the MV the only thing in the query, and are you selecting from it with an explicit reference to the MV name ? Or do you mean that you are running queries that in include the MV as one of the tables - perhaps after rewrite ?
MVs do not cause parallel execution. However I would check your parallel execution settings at the database level and the table and index level for this MV; and I would check the statistics on this MV to see if they are consistent with your opinion of its size.
Regards
Jonathan Lewis

PX DEQ CREDIT SEND BLKD on GV$

Hi All,
We experience "PX DEQ CREDIT SEND BLKD" wait , the pink spike on OEM, when there is query on GV$ in 10G(10.2.0.5), esp on
SELECT event, sql_id, sql_plan_hash_value, sql_opcode, session_id, session_serial#,
module, action, client_id, DECODE(wait_time, 0, 'W', 'C'), 1, time_waited,
service_hash, user_id, program, sample_time, p1, p2, p3, current_file#,
current_obj#, current_block#, qc_session_id, qc_instance_id, INST_ID
FROM gv$active_session_history WHERE sample_time >= :1 AND sample_time <= :2By DBSNMP user.
Even tested just
Select * from gv$active_session_history;The results is same waits on PX DEQ CREDIT SEND BLKD.
Since the issue we have increased
parallel_execution_message_size to 4k from 2K
Still its showing same waits.
I have some of my findings and reading on it though:
"PX Deq Credit: Send Blked" - there are two different scenarios where it can appear - one as an "idle" event and one as a performance threat.
When PX slaves feed a query co-ordinator (QC), only one can supply data at a time and the others go into the "PX Deq Credit: Send blkd" with a timeout of 2 seconds.
The end user doesn't see the result set appearing any more slowly because of this.
When one layer of PX slaves is passing data up the tree to the next layer, then there is competition for the PX table queues (virtual tables) with PX slaves blocked and unable to write into the virtual tables. Waits at this point are time-wasting events.
PX Deq Credit: send blkd indicate that a producer wants to send data to a consumer, but the consumer is still busy with previous requests so isn’t ready to receive it. i.e.
it’s falling behind. Reducing the DOP would reduce the number of times this happens and how long for. But we are not setting DOP on the query as its auto run by DBSNMP user.
I would be testing it with 8K soon. But I would like to know if anyone has any ideas or suggestions on the issue and if anyone else has encountered it.
Thanks

Anyone can please give in any pointers

PX Deq Credit: send blkd At AWR "Top 5 Timed Events"

PX Deq Credit: send blkd At Top 5 Timed Events
Hi ,
Below are examples of "Top 5 Timed Events" in my Staging data warehouse database.
ALWAYS , at the most Top 5 Timed Events is the event : PX Deq Credit: send blkd.
Oracle saids that its an idel event, but since it always at the the top of my AWR reports
and all the others events are far behind it , i have a feeling that it may indicate of
a problem.
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
PX Deq Credit: send blkd 3,152,038 255,152 81 95.6 Other
direct path read 224,839 4,046 18 1.5 User I/O
CPU time 3,217 1.2
direct path read temp 109,209 2,407 22 0.9 User I/O
db file scattered read 31,110 1,436 46 0.5 User I/O
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
PX Deq Credit: send blkd 6,846,579 16,359 2 50.4 Other
direct path read 101,363 5,348 53 16.5 User I/O
db file scattered read 105,377 4,991 47 15.4 User I/O
CPU time 3,795 11.7
direct path read temp 70,208 940 13 2.9 User I/O
Hir some more information:
Its a 500GB database on linux Red hat 4 with 8 CPUs and 16GB memory.
Its based on an ASM file system.
From the spfile:
SQL> show parameter parallel
NAME_COL_PLUS_SHOW_PARAM VALUE_COL_PLUS_SHOW_PARAM
parallel_adaptive_multi_user TRUE
parallel_automatic_tuning FALSE
parallel_execution_message_size 4096
parallel_instance_group
parallel_max_servers 240
parallel_min_percent 0
parallel_min_servers 0
parallel_server FALSE
parallel_server_instances 1
parallel_threads_per_cpu 2
recovery_parallelism 0
Thanks.

>
Metalink Note:280939.1 said:
"Consider the use of different number for the DOP on your tables.
On large tables and their indexes use high degree like #CPU.
For smaller tables use DOP (#CPU)/2 as start value.
Question 1:
"On large tables"--> Does Metalink mean to a large
table by its size (GB) or by number of rows ?
That's one of those vague things that people say without thinking that it
could have different meanings. Most people assume that a table that is
large in Gb is also large in number of rows.
As far as PQ is concerned I think that large numbers of rows may be more significant than large size, because (a) in multi-layer queries you pass rows around and (b) although the initial rows may be big you might not need all the columns to run the query, so Gb become less relevant once the data scan is complete
As a strategy for keeping DOP on the tables, by the way, it sounds quite
good. The difficulty is in the fine-tuning.
Question 2:
I checked how many parallel operations had been
downgraded and found that less than 4% had been
downgraded. Do you think that i still have to consider
reducing the DOP ?
Having lots of slaves means you are less likely to get downgrades. But it's the number of slaves active for a single query that introduce the dequeue waits - so yes, I think you do need to worry about the DOP. (Counter-intuitively, the few downgraded queries may have been performing better than the ones running at full DOP).
The difficulty is this - do you need to choose a strategy, or do you just need to fix a couple of queries.
Strategy 1: set DOP to 1 on all tables and indexes, then hint all queries that you think need to run parallel, possibly identifying a few tables and indexes that could benefit from an explicit setting for DOP.
Strategy 2: set DOP to #CPUs on all very large tables and their indexes and #CPUs/2 on the less large tables and their indexes. Check for any queries that perform very badly and either hint different degrees, or fine-tune the degree on a few tables.
Strategy 3: leave parallelism at default, identify particularly badly performing queries and either put in hints for DOP, or use them to identify any tables that need specific settings for DOP.
Starting from scratch, I would want to adopt strategy 1.
Starting from where you are at present, I would spend a little time checking to see if I could get some clues from any extreme queries - i.e. following strategy 3; but if under a lot of time pressure and saw no improvement I would switch to strategy 2.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

This SQL statement always in Top Activity, with PX Deq Credit: send blkd

Hi gurus,
The following SQL statement is always among the Top Activity. I can see the details in Enerprise manager that it suffers from PX Deq Credit: send blkd
This is the statement:
SELECT S.Product, S.WH_CODE, S.RACK, S.BATCH, S.EXP_DATE, FLOOR(Qty_Beg) QtyBeg_B,
        ROUND(f_convert_qty(S.PRODUCT, Qty_Beg-FLOOR(Qty_Beg), P.UOM_K ), 0) QtyBeg_K,
        FLOOR(Qty_In) QtyIn_B, ROUND(f_convert_qty(S.PRODUCT, Qty_In-FLOOR(Qty_In), P.UOM_K), 0) QtyIn_K,
        FLOOR(Qty_Out) QtyOut_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Out-FLOOR(Qty_Out), P.UOM_K ), 0) QtyOut_K,
        FLOOR(Qty_Adj) QtyAdj_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Adj-FLOOR(Qty_Adj), P.UOM_K ), 0) QtyAdj_K,
        FLOOR(Qty_End) QtyEnd_B, ROUND(f_convert_qty(S.PRODUCT, Qty_End-FLOOR(Qty_End), P.UOM_K ), 0) QtyEnd_K,
        S.LOC_CODE
        FROM V_STOCK_DETAIL S
        JOIN PRODUCTS P ON P.PRODUCT = S.PRODUCT
        WHERE S.Product = :pProduct AND S.WH_CODE = :pWhCode AND S.LOC_CODE = :pLocCode;The statement is invoked by our front end (web based app) for a browse table displayed on a web page. The result can be 10 to 8000. It is used to display the current stock availability for a particular product in a particular warehouse. The stock availability it self is kept in a View : V_Stock_Detail
These are the parameters relevant to the optimizer:
SQL> show parameter user_dump_dest
user_dump_dest                       string   /u01/app/oracle/admin/ITTDB/udump
SQL> show parameter optimizer
_optimizer_cost_based_transformation string   OFF
optimizer_dynamic_sampling           integer 2
optimizer_features_enable            string   10.2.0.3
optimizer_index_caching              integer 0
optimizer_index_cost_adj             integer 100
optimizer_mode                       string   ALL_ROWS
optimizer_secure_view_merging        boolean TRUE
SQL> show parameter db_file_multi
db_file_multiblock_read_count        integer 16
SQL> show parameter db_block_size column sname format a20 column pname format a20
db_block_size                        integer 8192Here is the output of EXPLAIN PLAN:
SQL> explain plan for
SELECT S.Product, S.WH_CODE, S.RACK, S.BATCH, S.EXP_DATE, FLOOR(Qty_Beg) QtyBeg_B,
    ROUND(f_convert_qty(S.PRODUCT, Qty_Beg-FLOOR(Qty_Beg), P.UOM_K ), 0) QtyBeg_K,
    FLOOR(Qty_In) QtyIn_B, ROUND(f_convert_qty(S.PRODUCT, Qty_In-FLOOR(Qty_In), P.UOM_K), 0) QtyIn_K,
    FLOOR(Qty_Out) QtyOut_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Out-FLOOR(Qty_Out), P.UOM_K ), 0) QtyOut_K,
    FLOOR(Qty_Adj) QtyAdj_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Adj-FLOOR(Qty_Adj), P.UOM_K ), 0) QtyAdj_K,
    FLOOR(Qty_End) QtyEnd_B, ROUND(f_convert_qty(S.PRODUCT, Qty_End-FLOOR(Qty_End), P.UOM_K ), 0) QtyEnd_K,
    S.LOC_CODE
    FROM V_STOCK_DETAIL S
    JOIN PRODUCTS P ON P.PRODUCT = S.PRODUCT
    WHERE S.Product = :pProduct AND S.WH_CODE = :pWhCode AND S.LOC_CODE = :pLocCode
Explain complete.
Elapsed: 00:00:00:31
SQL> select * from table(dbms_xplan.display)
PLAN_TABLE_OUTPUT
Plan hash value: 3252950027
| Id | Operation                               | Name                | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ
Distrib |
|   0 | SELECT STATEMENT                        |                     |     1 |   169 |     6 (17)| 00:00:01 |        |      |
         |
|   1 | PX COORDINATOR                         |                     |       |       |            |          |        |      |
         |
|   2 |   PX SEND QC (RANDOM)                   | :TQ10003            |     1 |   169 |     6 (17)| 00:00:01 | Q1,03 | P->S | QC
(RAND) |
|   3 |    HASH GROUP BY                        |                     |     1 |   169 |     6 (17)| 00:00:01 | Q1,03 | PCWP |
         |
|   4 |     PX RECEIVE                          |                     |     1 |   169 |     6 (17)| 00:00:01 | Q1,03 | PCWP |
         |
|   5 |      PX SEND HASH                       | :TQ10002            |     1 |   169 |     6 (17)| 00:00:01 | Q1,02 | P->P | HA
SH       |
|   6 |       HASH GROUP BY                     |                     |     1 |   169 |     6 (17)| 00:00:01 | Q1,02 | PCWP |
         |
|   7 |        NESTED LOOPS OUTER               |                     |     1 |   169 |     5   (0)| 00:00:01 | Q1,02 | PCWP |
         |
|   8 |         MERGE JOIN CARTESIAN            |                     |     1 |   119 |     4   (0)| 00:00:01 | Q1,02 | PCWP |
         |
|   9 |          SORT JOIN                      |                     |       |       |            |          | Q1,02 | PCWP |
         |
| 10 |           NESTED LOOPS                  |                     |     1 |    49 |     4   (0)| 00:00:01 | Q1,02 | PCWP |
         |
| 11 |            BUFFER SORT                  |                     |       |       |            |          | Q1,02 | PCWC |
         |
| 12 |             PX RECEIVE                  |                     |       |       |            |          | Q1,02 | PCWP |
         |
| 13 |              PX SEND BROADCAST          | :TQ10000            |       |       |            |          |        | S->P | BR
OADCAST |
|* 14 |               INDEX RANGE SCAN          | PRODUCTS_IDX2       |     1 |    25 |     2   (0)| 00:00:01 |        |      |
         |
| 15 |            PX BLOCK ITERATOR            |                     |     1 |    24 |     2   (0)| 00:00:01 | Q1,02 | PCWC |
         |
|* 16 |             MAT_VIEW ACCESS FULL        | MV_CONVERT_UOM      |     1 |    24 |     2   (0)| 00:00:01 | Q1,02 | PCWP |
         |
| 17 |          BUFFER SORT                    |                     |     1 |    70 |     2   (0)| 00:00:01 | Q1,02 | PCWP |
         |
| 18 |           BUFFER SORT                   |                     |       |       |            |          | Q1,02 | PCWC |
         |
| 19 |            PX RECEIVE                   |                     |     1 |    70 |     4   (0)| 00:00:01 | Q1,02 | PCWP |
         |
| 20 |             PX SEND BROADCAST           | :TQ10001            |     1 |    70 |     4   (0)| 00:00:01 |        | S->P | BR
OADCAST |
|* 21 |              TABLE ACCESS BY INDEX ROWID| STOCK               |     1 |    70 |     4   (0)| 00:00:01 |        |      |
         |
|* 22 |               INDEX RANGE SCAN          | STOCK_PK            |     1 |       |     2   (0)| 00:00:01 |        |      |
         |
|* 23 |         TABLE ACCESS BY INDEX ROWID     | MV_TRANS_STOCK      |     1 |    50 |     3   (0)| 00:00:01 | Q1,02 | PCWP |
         |
|* 24 |          INDEX RANGE SCAN               | MV_TRANS_STOCK_IDX1 |     1 |       |     2   (0)| 00:00:01 | Q1,02 | PCWP |
         |
Predicate Information (identified by operation id):
14 - access("P"."PRODUCT"=:PPRODUCT)
16 - filter("CON"."PRODUCT"=:PPRODUCT)
21 - filter("STOCK"."LOC_CODE"=:PLOCCODE)
22 - access("STOCK"."PRODUCT"=:PPRODUCT AND "STOCK"."WH_CODE"=:PWHCODE)
23 - filter("STS"(+)='N')
24 - access("PRODUCT"(+)=:PPRODUCT AND "WH_CODE"(+)=:PWHCODE AND "LOC_CODE"(+)=:PLOCCODE AND "RACK"(+)="STOCK"."RACK" AND
              "BATCH"(+)="STOCK"."BATCH" AND "EXP_DATE"(+)="STOCK"."EXP_DATE")
42 rows selected.
Elapsed: 00:00:00:06Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
SQL> SELECT S.Product, S.WH_CODE, S.RACK, S.BATCH, S.EXP_DATE, FLOOR(Qty_Beg) QtyBeg_B,
    ROUND(f_convert_qty(S.PRODUCT, Qty_Beg-FLOOR(Qty_Beg), P.UOM_K ), 0) QtyBeg_K,
    FLOOR(Qty_In) QtyIn_B, ROUND(f_convert_qty(S.PRODUCT, Qty_In-FLOOR(Qty_In), P.UOM_K), 0) QtyIn_K,
    FLOOR(Qty_Out) QtyOut_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Out-FLOOR(Qty_Out), P.UOM_K ), 0) QtyOut_K,
    FLOOR(Qty_Adj) QtyAdj_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Adj-FLOOR(Qty_Adj), P.UOM_K ), 0) QtyAdj_K,
    FLOOR(Qty_End) QtyEnd_B, ROUND(f_convert_qty(S.PRODUCT, Qty_End-FLOOR(Qty_End), P.UOM_K ), 0) QtyEnd_K,
    S.LOC_CODE
    FROM V_STOCK_DETAIL S
    JOIN PRODUCTS P ON P.PRODUCT = S.PRODUCT
    WHERE S.Product = :pProduct AND S.WH_CODE = :pWhCode AND S.LOC_CODE = :pLocCode
Execution Plan
   0      SELECT STATEMENT Optimizer Mode=ALL_ROWS   1   169   6
   1    0   PX COORDINATOR
   2    1     PX SEND QC (RANDOM) SYS.:TQ10003 1   169   6   :Q1003 P->S   QC (RANDOM)
   3    2       HASH GROUP BY   1   169   6   :Q1003 PCWP
   4    3         PX RECEIVE   1   169   6   :Q1003 PCWP
   5    4           PX SEND HASH SYS.:TQ10002 1   169   6   :Q1002 P->P   HASH
   6    5             HASH GROUP BY   1   169   6   :Q1002 PCWP
   7    6               NESTED LOOPS OUTER   1   169   5   :Q1002 PCWP
   8    7                 MERGE JOIN CARTESIAN   1   119   4   :Q1002 PCWP
   9    8                   SORT JOIN          :Q1002 PCWP
10    9                     NESTED LOOPS   1   49   4   :Q1002 PCWP
11   10                       BUFFER SORT          :Q1002 PCWC
12   11                         PX RECEIVE          :Q1002 PCWP
13   12                           PX SEND BROADCAST SYS.:TQ10000           S->P   BROADCAST
14   13                             INDEX RANGE SCAN ITT_NEW.PRODUCTS_IDX2 1   25   2
15   10                       PX BLOCK ITERATOR   1   24   2   :Q1002 PCWC
16   15                         MAT_VIEW ACCESS FULL ITT_NEW.MV_CONVERT_UOM 1   24   2   :Q1002 PCWP
17    8                   BUFFER SORT   1   70   2   :Q1002 PCWP
18   17                     BUFFER SORT          :Q1002 PCWC
19   18                       PX RECEIVE   1   70   4   :Q1002 PCWP
20   19                         PX SEND BROADCAST SYS.:TQ10001 1   70   4      S->P   BROADCAST
21   20                           TABLE ACCESS BY INDEX ROWID ITT_NEW.STOCK 1   70   4
22   21                             INDEX RANGE SCAN ITT_NEW.STOCK_PK 1     2
23    7                 TABLE ACCESS BY INDEX ROWID ITT_NEW.MV_TRANS_STOCK 1   50   3   :Q1002 PCWP
24   23                   INDEX RANGE SCAN ITT_NEW.MV_TRANS_STOCK_IDX1 1     2   :Q1002 PCWP
Statistics
        570 recursive calls
          0 physical write total IO requests
          0 physical write total multi block requests
          0 physical write total bytes
          0 physical writes direct temporary tablespace
          0 java session heap live size max
          0 java session heap object count
          0 java session heap object count max
          0 java session heap collected count
          0 java session heap collected bytes
         83 rows processed
Elapsed: 00:00:03:24
SQL> disconnect
Commit complete
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining optionsThe TKPROF output for this statement looks like the following:
TKPROF: Release 10.2.0.3.0 - Production on Thu Apr 23 12:39:29 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: ittdb_ora_9566_mytrace1.trc
Sort options: default
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
SELECT S.Product, S.WH_CODE, S.RACK, S.BATCH, S.EXP_DATE, FLOOR(Qty_Beg) QtyBeg_B,
    ROUND(f_convert_qty(S.PRODUCT, Qty_Beg-FLOOR(Qty_Beg), P.UOM_K ), 0) QtyBeg_K,
    FLOOR(Qty_In) QtyIn_B, ROUND(f_convert_qty(S.PRODUCT, Qty_In-FLOOR(Qty_In), P.UOM_K), 0) QtyIn_K,
    FLOOR(Qty_Out) QtyOut_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Out-FLOOR(Qty_Out), P.UOM_K ), 0) QtyOut_K,
    FLOOR(Qty_Adj) QtyAdj_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Adj-FLOOR(Qty_Adj), P.UOM_K ), 0) QtyAdj_K,
    FLOOR(Qty_End) QtyEnd_B, ROUND(f_convert_qty(S.PRODUCT, Qty_End-FLOOR(Qty_End), P.UOM_K ), 0) QtyEnd_K,
    S.LOC_CODE
    FROM V_STOCK_DETAIL S
    JOIN PRODUCTS P ON P.PRODUCT = S.PRODUCT
    WHERE S.Product = :pProduct AND S.WH_CODE = :pWhCode AND S.LOC_CODE = :pLocCode
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.04       0.12          0         10          4           0
Fetch       43      0.05       2.02          0         73          0          83
total       45      0.10       2.15          0         83          4          83
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 164
Rows     Row Source Operation
     83 PX COORDINATOR (cr=83 pr=0 pw=0 time=2086576 us)
      0   PX SEND QC (RANDOM) :TQ10003 (cr=0 pr=0 pw=0 time=0 us)
      0    HASH GROUP BY (cr=0 pr=0 pw=0 time=0 us)
      0     PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
      0      PX SEND HASH :TQ10002 (cr=0 pr=0 pw=0 time=0 us)
      0       HASH GROUP BY (cr=0 pr=0 pw=0 time=0 us)
      0        NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us)
      0         MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us)
      0          SORT JOIN (cr=0 pr=0 pw=0 time=0 us)
      0           NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us)
      0            BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0             PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
      0              PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us)
      1               INDEX RANGE SCAN PRODUCTS_IDX2 (cr=2 pr=0 pw=0 time=62 us)(object id 135097)
      0            PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us)
      0             MAT_VIEW ACCESS FULL MV_CONVERT_UOM (cr=0 pr=0 pw=0 time=0 us)
      0          BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0           BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0            PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
      0             PX SEND BROADCAST :TQ10001 (cr=0 pr=0 pw=0 time=0 us)
     83              TABLE ACCESS BY INDEX ROWID STOCK (cr=78 pr=0 pw=0 time=1635 us)
     83               INDEX RANGE SCAN STOCK_PK (cr=4 pr=0 pw=0 time=458 us)(object id 135252)
      0         TABLE ACCESS BY INDEX ROWID MV_TRANS_STOCK (cr=0 pr=0 pw=0 time=0 us)
      0          INDEX RANGE SCAN MV_TRANS_STOCK_IDX1 (cr=0 pr=0 pw=0 time=0 us)(object id 143537)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
PX Deq: Join ACK                               17        0.00          0.00
PX qref latch                                   2        0.00          0.00
PX Deq Credit: send blkd                       72        1.95          2.00
PX Deq: Parse Reply                            26        0.01          0.01
SQL*Net message to client                      43        0.00          0.00
PX Deq: Execute Reply                          19        0.00          0.01
SQL*Net message from client                    43        0.00          0.04
PX Deq: Signal ACK                             12        0.00          0.00
enq: PS - contention                            1        0.00          0.00
********************************************************************************The DBMS_XPLAN.DISPLAY_CURSOR output:
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'))
PLAN_TABLE_OUTPUT
SQL_ID 402b8st7vt6ku, child number 2
SELECT /*+ gather_plan_statistics */          S.Product, S.WH_CODE, S.RACK, S.BATCH, S.EXP_DATE, FLOOR(Qty_Beg) QtyBeg_B,
ROUND(f_convert_qty(S.PRODUCT, Qty_Beg-FLOOR(Qty_Beg), P.UOM_K ), 0) QtyBeg_K,      FLOOR(Qty_In) QtyIn_B, ROUND(f_convert_qty(S.P
RODUCT,
Qty_In-FLOOR(Qty_In), P.UOM_K), 0) QtyIn_K,      FLOOR(Qty_Out) QtyOut_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Out-FLOOR(Qty_Out), P
.UOM_K ),
0) QtyOut_K,      FLOOR(Qty_Adj) QtyAdj_B, ROUND(f_convert_qty(S.PRODUCT, Qty_Adj-FLOOR(Qty_Adj), P.UOM_K ), 0) QtyAdj_K,
FLOOR(Qty_End) QtyEnd_B, ROUND(f_convert_qty(S.PRODUCT, Qty_End-FLOOR(Qty_End), P.UOM_K ), 0) QtyEnd_K,      S.LOC_CODE      FROM
V_STOCK_DETAIL S      JOIN PRODUCTS P ON P.PRODUCT = S.PRODUCT      WHERE S.Product = :pProduct AND S.WH_CODE = :pWhCode AND S.LOC
_CODE =
:pLocCode
Plan hash value: 3252950027
| Id | Operation                               | Name                | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem |
1Mem | Used-Mem |
|   1 | PX COORDINATOR                         |                     |      1 |        |     83 |00:00:02.25 |      83 |       |
      |          |
|   2 |   PX SEND QC (RANDOM)                   | :TQ10003            |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
|   3 |    HASH GROUP BY                        |                     |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
|   4 |     PX RECEIVE                          |                     |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
|   5 |      PX SEND HASH                       | :TQ10002            |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
|   6 |       HASH GROUP BY                     |                     |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
|   7 |        NESTED LOOPS OUTER               |                     |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
|   8 |         MERGE JOIN CARTESIAN            |                     |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
|   9 |          SORT JOIN                      |                     |      0 |        |      0 |00:00:00.01 |       0 | 73728 |
73728 |          |
| 10 |           NESTED LOOPS                  |                     |      0 |      1 |      0 |00:00:00.01 |       0 |       |
      |          |
| 11 |            BUFFER SORT                  |                     |      0 |        |      0 |00:00:00.01 |       0 | 73728 |
73728 |          |
| 12 |             PX RECEIVE                  |                     |      0 |        |      0 |00:00:00.01 |       0 |       |
      |          |
| 13 |              PX SEND BROADCAST          | :TQ10000            |      0 |        |      0 |00:00:00.01 |       0 |       |
      |          |
|* 14 |               INDEX RANGE SCAN          | PRODUCTS_IDX2       |      1 |      1 |      1 |00:00:00.01 |       2 |       |
      |          |
| 15 |            PX BLOCK ITERATOR            |                     |      0 |      1 |      0 |00:00:00.01 |       0 |       |
      |          |
|* 16 |             MAT_VIEW ACCESS FULL        | MV_CONVERT_UOM      |      0 |      1 |      0 |00:00:00.01 |       0 |       |
      |          |
| 17 |          BUFFER SORT                    |                     |      0 |     21 |      0 |00:00:00.01 |       0 | 73728 |
73728 |          |
| 18 |           BUFFER SORT                   |                     |      0 |        |      0 |00:00:00.01 |       0 | 73728 |
73728 |          |
| 19 |            PX RECEIVE                   |                     |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
| 20 |             PX SEND BROADCAST           | :TQ10001            |      0 |     21 |      0 |00:00:00.01 |       0 |       |
      |          |
|* 21 |              TABLE ACCESS BY INDEX ROWID| STOCK               |      1 |     21 |     83 |00:00:00.01 |      78 |       |
      |          |
|* 22 |               INDEX RANGE SCAN          | STOCK_PK            |      1 |     91 |     83 |00:00:00.01 |       4 |       |
      |          |
|* 23 |         TABLE ACCESS BY INDEX ROWID     | MV_TRANS_STOCK      |      0 |      1 |      0 |00:00:00.01 |       0 |       |
      |          |
|* 24 |          INDEX RANGE SCAN               | MV_TRANS_STOCK_IDX1 |      0 |      1 |      0 |00:00:00.01 |       0 |       |
      |          |
Predicate Information (identified by operation id):
14 - access("P"."PRODUCT"=:PPRODUCT)
16 - access(:Z>=:Z AND :Z<=:Z)
       filter("CON"."PRODUCT"=:PPRODUCT)
21 - filter("STOCK"."LOC_CODE"=:PLOCCODE)
22 - access("STOCK"."PRODUCT"=:PPRODUCT AND "STOCK"."WH_CODE"=:PWHCODE)
23 - filter("STS"='N')
24 - access("PRODUCT"=:PPRODUCT AND "WH_CODE"=:PWHCODE AND "LOC_CODE"=:PLOCCODE AND "RACK"="STOCK"."RACK" AND "BATCH"="STOCK"."B
ATCH" AND
              "EXP_DATE"="STOCK"."EXP_DATE")
53 rows selected.
Elapsed: 00:00:00:12I'm looking forward for suggestions how to improve the performance of this statement.
Thank you very much,
xtanto

xtanto wrote:
Hi sir,
How to prevent the query from doing parallel query ?
Because as you see actually I am not issuing any Parallel hints in the query.
Thank you,
xtantoKristanto,
there are a couple of points to consider:
1. Your SQL*Plus version seems to be outdated. Please use a SQL*Plus version that corresponds to your database version. E.g. the AUTOTRACE output is odd.
2. I would suggest to repeat your exercise using serial execution (the plan, the autotrace, the tracing). You can disable parallel queries by issuing this in your session:
ALTER SESSION DISABLE PARALLEL QUERY;
This way the output of the tools is much more meaningful, however you might get a different execution plan, therefore the results might not be representative for your parallel execution.
3. The function calls might pose a problem. If they are, one possible damage limitation has been provided by hoek. Even better would be then to replace the PL/SQL function with equivalent plain SQL. However since you say that it generates not too many rows it might not harm here too much. You can check the impact of the functions by running a similar query but omitting the function calls.
4. The parallel execution plan contains a MERGE JOIN CARTESIAN operation which could be an issue if the estimates of the optimizer are incorrect. If the serial execution still uses this operation the TKPROF and DBMS_XPLAN.DISPLAY_CURSOR output will reveal whether this is a problem or not.
5. The execution of the statement seems to take on 2-3 seconds in your tests. Is this in the right ballpark? If yes, why should this statement then be problematic? How often does it get executed?
6. The statement uses bind variables, so you might have executions that use different execution plans depending on the bind values passed when the statement got optimized. You can use DBMS_XPLAN.DISPLAY_CURSOR using NULL as "child_number" parameter or DBMS_XPLAN.DISPLAY_AWR (if you have a AWR license) to check if you have multiple execution plans for the statement. Please note that older versions might have already been aged out of the shared pool, so the AWR repository might be a more reliable source (but only if the statement has been sampled).
7. You have disabled cost based transformations: "_optimizer_cost_based_transformation" = OFF. Why?
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

PX Deq Credit: send blkd (AWR)

Hello,
We are having some performance issue. and i tried taking an AWR report and the top events are as follows.
PX Deq Credit: send blkd 170,984 14,575 85 82.0 Other
CPU time 1,544 8.7
PX Deq: Signal ACK 183,850 979 5 5.5 Other
db file sequential read 20,979 102 5 .6 User I/O
kksfbc child completion 860 33 38 .2 Other
what in the world is PX Deq Credit: send blkd event? As i use Database control to monitor the performance. And for active session its allways at the top with "OTHERS". i am talking about avg active session. the pink which indicates OTHER is allways high. And when i look in that others catageory. i get pointed to PX Deq Credit: send blkd ...
so what in the world is PX Deq Credit: send blkd and how can we get this down. This is 10g on AIX. some of the helpfull parameters
sga set for 8gigs
pga about 1 gig
processess is 150
parallel_max_servers is 80
this box have 16 gigs memory and only one database on it.
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
NAME TYPE
VALUE
parallel_max_servers integer
80
parallel_min_percent integer
0
parallel_min_servers integer
0
parallel_server boolean
FALSE
NAME TYPE
VALUE
parallel_server_instances integer
1
parallel_threads_per_cpu integer
2
recovery_parallelism integer

Well if you do have only 4 cpu's then I think you should address the degree of parallelsim you're using first.
However having said that I'd urge you to just experiment with the message size. I can think of theoretical reasons why either small or large sizes could be beneficial here, and I found that a higher size gave fewer waits and a longer average duration that netted out to a marginal benefit. The default is at the lower end of possible values.
First though, don't choke those CPU's too hard if you can avoid it.

PX Deq Credit: send blkd -

Linux 2.6.18-128.e15 x86-64
Oracle DB 11.1.0.7
Clusterware 11.1.0.7
ASM 11.1.0.7
Eight (8) node rac cluster
I am stumped and am asking for some guidance before resorting to creating a SR.
The query: " select count(*) from gv$transaction where start_date < :b1 " hangs when more than one node in the cluster is up. The sql statement is executed from within a stored procedure. Checking wait events yields the "PX Deq Credit: send blkd". If I execute the same sql statement standalone or within an anonomous pl/sql block from any node the statement works fine. When invoked from within the application it hangs every time. The package is wrapped so I cannot see what has transpired prior to this statement. The offending statement never completes. I have googled and checked metalink without much success.
Ran the racdiag.sql script in hope I could spot something obvious and in preparation to open up a SR (sigh). Again I am stumped for the moment. Thank you.
RCVR RCVRINST SID SNDR EVENT SNDRINST SNDRSID
A QC 4 2075 P#### PX Deq Credit: send blkd 1
PZ98 4 2089 QC PX Deq: Execution Msg 196609 2140
Username QC/Slave SlaveSet SID Slave INS STATE WAIT_EVENT QC SID QC INS Req. DOP Actual DOP
GENEVA_ADMIN QC 2075 4 WAIT PX Deq Credit: send blkd 2075
SYS QC 2140 4 WAIT PX Deq: Execute Reply 2140
- pz98 (Slave) 1 2058 1 WAIT PX Deq: Execution Msg 2140 4 8 8
- pz98 (Slave) 1 2028 2 WAIT PX Deq: Execution Msg 2140 4 8 8
- pz98 (Slave) 1 2127 3 WAIT PX Deq: Execution Msg 2140 4 8 8
- pz98 (Slave) 1 2096 4 WAIT PX Deq: Execution Msg 2140 4 8 8
- pz98 (Slave) 1 2164 5 WAIT PX Deq: Execution Msg 2140 4 8 8
- pz98 (Slave) 1 2034 6 WAIT PX Deq: Execution Msg 2140 4 8 8
- pz98 (Slave) 1 2110 7 WAIT PX Deq: Execution Msg 2140 4 8 8
- pz98 (Slave) 1 2009 8 WAIT PX Deq: Execution Msg 2140 4 8 8
10 rows selected.

Hi,
Even I got the same issue on ORACLE 10gR2. I was told that it is a ORACLE bug . Refer to Metalink note 762412.1 . This might be helpful.
We are still planning to implenment the solution but the patch upgrade si not yet scheduled. Please let me know, if this solves u r issue.

PX Deq Credit: send blkd is getting hang while refreshing materialized view

Hi All,
When we are refreshing materialized view. It is taking more than 2.30 mins. Initially it was taking 1.40 Mins.
We are using parallel and base tables are partitioned. When i checked the tkprof report i see lots of insert query is mostly waiting for PX Deq Credit: send blkd event. When i check the ASH report I don't find any query related to MV was running but still MV refresh was going on
TKPROF: Release 11.2.0.1.0 - Development on Wed Jun 5 16:27:29 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: CHDFCI_p001_43384918_PARALLEL.trc
Sort options: exeela prsela fchela
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
EXPLAIN PLAN option disabled.
SQL ID: 2x210q5g30m4t
Plan Hash: 2058446196
INSERT /*+ BYPASS_RECURSIVE_CHECK APPEND */ INTO
"APPS"."GL_BAL_MV" SELECT * FROM
GL_BAL_V
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1    362.20    9372.04    1158765          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        2    362.20    9372.04    1158765          0          0           0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 175     (recursive depth: 1)
Rows     Row Source Operation
      0 LOAD AS SELECT (cr=0 pr=0 pw=0 time=0 us)
      0   PX COORDINATOR (cr=0 pr=0 pw=0 time=0 us)
      0    PX SEND QC (RANDOM) :TQ10003 (cr=0 pr=0 pw=0 time=0 us cost=1041298 size=389555904 card=2028937)
78448967     HASH JOIN BUFFERED (cr=0 pr=1158765 pw=1158765 time=276842112 us cost=1041298 size=389555904 card=2028937)
410944      BUFFER SORT (cr=0 pr=0 pw=0 time=492466 us)
410944       PX RECEIVE (cr=0 pr=0 pw=0 time=34526636 us cost=64715 size=147944250 card=1643825)
      0        PX SEND HASH :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
      0         PARTITION RANGE ALL PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
      0          TABLE ACCESS FULL GL_CODE_COMBINATIONS PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
78448967      PX RECEIVE (cr=0 pr=0 pw=0 time=2453949696 us cost=976582 size=395060280 card=3873140)
      0       PX SEND HASH :TQ10002 (cr=0 pr=0 pw=0 time=0 us cost=976582 size=395060280 card=3873140)
      0        HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=976582 size=395060280 card=3873140)
      0         BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0          PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0           PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0            HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0             TABLE ACCESS FULL GL_SETS_OF_BOOKS (cr=0 pr=0 pw=0 time=0 us cost=7 size=108 card=6)
      0             TABLE ACCESS FULL GL_PERIODS (cr=0 pr=0 pw=0 time=0 us cost=24 size=44640 card=1240)
      0         PX BLOCK ITERATOR PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=976550 size=30099548160 card=627073920)
      0          TABLE ACCESS FULL GL_BALANCES PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=976550 size=30099548160 card=627073920)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
PX Deq: Execution Msg                           3        0.16          0.17
PX Deq Credit: send blkd                  1061004        1.99       5084.61
PX Deq: Table Q Normal                     250856        2.00       2306.87
asynch descriptor resize                        1        0.00          0.00
Disk file operations I/O                       10        0.23          0.26
direct path write temp                       3608        1.20        958.39
latch free                                     26        0.02          0.19
PX qref latch                             7647924        0.05         11.85
direct path read temp                         578        0.43         35.19
PX Deq Credit: need buffer                   4037        0.08          5.84
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        0      0.00       0.00          0          0          0           0
Misses in library cache during parse: 0
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
PX Deq: Execution Msg                           3        0.47          0.75
PX Deq: Slave Session Stats                     1        0.15          0.15
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1    362.20    9372.04    1158765          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        2    362.20    9372.04    1158765          0          0           0
Misses in library cache during parse: 0
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
PX Deq: Execution Msg                           3        0.16          0.17
PX Deq Credit: send blkd                  1061004        1.99       5084.61
PX Deq: Table Q Normal                     250856        2.00       2306.87
asynch descriptor resize                        1        0.00          0.00
Disk file operations I/O                       10        0.23          0.26
direct path write temp                       3608        1.20        958.39
latch free                                     26        0.02          0.19
PX qref latch                             7647924        0.05         11.85
direct path read temp                         578        0.43         35.19
PX Deq Credit: need buffer                   4037        0.08          5.84
    1 user SQL statements in session.
    0 internal SQL statements in session.
    1 SQL statements in session.
    0 statements EXPLAINed in this session.
Trace file: CHDFCI_p001_43384918_PARALLEL.trc
Trace file compatibility: 11.1.0.7
Sort options: exeela prsela fchela
       1 session in tracefile.
       1 user SQL statements in trace file.
       0 internal SQL statements in trace file.
       1 SQL statements in trace file.
       1 unique SQL statements in trace file.
8986825 lines in trace file.
    9372 elapsed seconds in trace file.When i checked the ASH report during this time. I don't see anything running related to MV.
I am using parallel degree 8 for GL_BALANCES.
Please suggest.

Hi
After enabling the DML also, same plan is getting generated.
MV refresh is taking same time.
| Id | Operation                    | Name                 | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ |IN-OUT| PQ Distrib |
PLAN_TABLE_OUTPUT
|   0 | INSERT STATEMENT             |                      |       |       | 1027K(100)|          |       |       |        |      |            |
|   1 | LOAD AS SELECT              |                      |       |       |            |          |       |       |        |      |            |
|   2 |   PX COORDINATOR             |                      |       |       |            |          |       |       |        |      |            |
|   3 |    PX SEND QC (RANDOM)       | :TQ10003             | 1998K|   365M| 1027K (1)|999:59:59 |       |       | Q1,03 | P->S | QC (RAND) |
|   4 |     HASH JOIN BUFFERED       |                      | 1998K|   365M| 1027K (1)|999:59:59 |       |       | Q1,03 | PCWP |            |
|   5 |      BUFFER SORT             |                      |       |       |            |          |       |       | Q1,03 | PCWC |            |
|   6 |       PX RECEIVE             |                      | 1642K|   141M| 64715   (0)|999:59:59 |       |       | Q1,03 | PCWP |            |
|   7 |        PX SEND HASH          | :TQ10001             | 1642K|   141M| 64715   (0)|999:59:59 |       |       |        | S->P | HASH       |
|   8 |         PARTITION RANGE ALL |                      | 1642K|   141M| 64715   (0)|999:59:59 |     1 |    39 |        |      |            |
|   9 |          TABLE ACCESS FULL   | GL_CODE_COMBINATIONS | 1642K|   141M| 64715   (0)|999:59:59 |     1 |    39 |        |      |            |
| 10 |      PX RECEIVE              |                      | 3820K|   371M|   963K (1)|999:59:59 |       |       | Q1,03 | PCWP |            |
PLAN_TABLE_OUTPUT
| 11 |       PX SEND HASH           | :TQ10002             | 3820K|   371M|   963K (1)|999:59:59 |       |       | Q1,02 | P->P | HASH       |
| 12 |        HASH JOIN             |                      | 3820K|   371M|   963K (1)|999:59:59 |       |       | Q1,02 | PCWP |            |
| 13 |         BUFFER SORT          |                      |       |       |            |          |       |       | Q1,02 | PCWC |            |
| 14 |          PX RECEIVE          |                      | 2480 |   130K|    32   (4)| 00:40:12 |       |       | Q1,02 | PCWP |            |
| 15 |           PX SEND BROADCAST | :TQ10000             | 2480 |   130K|    32   (4)| 00:40:12 |       |       |        | S->P | BROADCAST |
| 16 |            HASH JOIN         |                      | 2480 |   130K|    32   (4)| 00:40:12 |       |       |        |      |            |
| 17 |             TABLE ACCESS FULL| GL_SETS_OF_BOOKS     |     6 |   108 |     7   (0)| 00:08:48 |       |       |        |      |            |
| 18 |             TABLE ACCESS FULL| GL_PERIODS           | 1240 | 44640 |    24   (0)| 00:30:09 |       |       |        |      |            |
| 19 |         PX BLOCK ITERATOR    |                      |   618M|    27G|   963K (1)|999:59:59 |     1 |    39 | Q1,02 | PCWC |            |
| 20 |          TABLE ACCESS FULL   | GL_BALANCES          |   618M|    27G|   963K (1)|999:59:59 |     1 |    39 | Q1,02 | PCWP |            |
--------------------------------------------------------------------------------------------------------------------------------------------------Please find the completion time for MV refresh.
14:58:47 SQL> alter session enable parallel dml;
Session altered.
Elapsed: 00:00:00.27
14:59:50 SQL> exec dbms_mview.REFRESH ('GL_BAL_MV','C',atomic_refresh=>FALSE);
PL/SQL procedure successfully completed.
Elapsed: 02:30:58.37
Thanks

"PX Deq Credit: send blkd" , Oracle 11g, ASH, and OEM

In our 10g databases (monitored by OEM 10g) we can sometimes see this event depicted magnificently in Pepto-Bismol pink, when a developer has overdone it with a parallelism hint or table parallelism setting.
Last night, on one of our 11g databases, monitored by OEM 12c, we were trying to see if parallelism would help 2 long-running queries. (it was not a success.) I was specifically watching for the PX Deq Credit: send blkd and similar waits via OEM, and I also ran several ASH reports to verify there were no unusual events. No sign of these waits.
Overnight, the developer who was working with me sent me a screen shot from Toad showing these waits. I looked again and still saw no signs via ASH or OEM. I queried DBA_HIST_ACTIVE_SESS_HISTORY and found some logged there from days or weeks ago but that was all. I ran an AWR report and sure enough:
                                                             Avg
                                        %Time Total Wait    wait    Waits   % DB
Event                             Waits -outs   Time (s)    (ms)     /txn   time
PX Deq Credit: send blkd     13,656,665     0    314,939      23 2,474.0(this was over an 8-hour span. )
Has something changed in Oracle 11g that prevents these from showing up in ASH or OEM?
Thanks,
Mike

Hi,
Its could be due to flush/Purge Logs runing every night as default DB Maintennace jobs
Thanks,
Ajay more

Top Time Event "PX Deq Credit: send blkd"

Hi,
I have this event on TOP of my Wait Events Statspack Report. Anyone know how to minimize the time of this event?? Increase the number os parallel_max_servers will help me???
Tks,
Paulo.

What's your Oracle version and OS ?
Are you using 8i with OPS (Oracle Parallel Server) ?

PX Deq wait event

Hi,
Statspack report me that on our database, there is wait event about this PX Deq :
PX Deq: Table Q Normal
PX Deq: Execute Reply
PX Deq Credit: send blkd
What is this exactly ?
Nicolas.

Here is some additional info from metalink.
PX Deq: Table Q Normal
Indicates that the slave wait for data to arrive on its input table queue.
In a parallel execution environment we have a producer consumer model.
One slave set works on the data ( e.g. read data from disk , do a join )
called the produces slave set and the other slave set waits to get the data
that the can start the work. The slaves in this slave set are called consumer.
The wait event "PX Deq: Table Q Normal" means that the slaves in the consumer
slave have to wait for rows( data ) from the other slave set that they can
start there work.
PX Deq: Execute Reply
The QC is expecting a response (acknowledgement) to a control message
from the slaves or is expecting to dequeue data from the producer slave set.
This means he waits that the slaves finished to execute the SQL statement
and that they send the result of the query back to the QC.

Wait event PX Deq: reap credit in Oracle 9.2.0.8

Hi,
Can you please explain me what does mean by "PX Deq: reap credit" wait event. My session is waiting on this event. Can you please suggest how to reduce this wait.
Thanks

Hi
oratst@ebsdevdb on /ebdbh/11g/data/cfgtoollogs/dbua/ebstest/upgrade1 # more Upgrade_Directive.log
Connected.
ODMA_DIRECTIVE:VERSION:9.2.0.8
ODMA_DIRECTIVE:MIGRATE_SID:
ODMA_DIRECTIVE:ORA:IGNORE:06512:
ODMA_DIRECTIVE:ORA:FATAL:00600:
ODMA_DIRECTIVE:ORA:FATAL:01012:
ODMA_DIRECTIVE:ORA:FATAL:01031:
ODMA_DIRECTIVE:ORA:FATAL:01034:
ODMA_DIRECTIVE:ORA:FATAL:01078:
ODMA_DIRECTIVE:ORA:FATAL:01092:
ODMA_DIRECTIVE:ORA:FATAL:01109:
ODMA_DIRECTIVE:ORA:FATAL:01119:
ODMA_DIRECTIVE:ORA:FATAL:01507:
ODMA_DIRECTIVE:ORA:FATAL:01722:
ODMA_DIRECTIVE:ORA:FATAL:03113:
ODMA_DIRECTIVE:ORA:FATAL:03114:
ODMA_DIRECTIVE:ORA:FATAL:07445:
ODMA_DIRECTIVE:ORA:FATAL:12560:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01650:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01651:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01652:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01653:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01654:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01655:
ODMA_DIRECTIVE:ORA:RECOVER_ROLL:01562:
ODMA_DIRECTIVE:ORA:RECOVER_INIT:04031:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:rdbms/admin/catupgrd.sql:
ODMA_DIRECTIVE:BOUNCE_DATABASE:UPGRADE:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:rdbms/admin/catuppst.sql:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:sqlplus/admin/help/hlpbld.sql helpus.sql:
Thanks
With Regards
A-Z

PX Deq: Execute Reply - Wait event

I am seeing PX Deq: Execute Reply wait event for a query which returns no data. From metalink I see this can be ignored.
Any suggestion is appreciated.

I am attaching explain plan. Not sure if this helps. Another prod database which has similiar plan works fine.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=205424 Card=1 Bytes=
142)
1 0 TABLE ACCESS* (BY INDEX ROWID) OF 'STG_TRD_SWAP_CF' (Cost= :Q804383
4 Card=1 Bytes=82) 001
2 1 NESTED LOOPS* (Cost=205424 Card=1 Bytes=142) :Q804383
001
3 2 HASH JOIN* (Cost=59005 Card=146419 Bytes=8785140) :Q804383
001
4 3 NESTED LOOPS* (Cost=3 Card=1 Bytes=25) :Q804383
000
5 4 VIEW (Cost=2 Card=1 Bytes=13)
6 5 SORT (AGGREGATE)
7 6 INDEX (FULL SCAN (MIN/MAX)) OF 'T_HUB_CONTROL_
TRADE_HDR_PK' (UNIQUE) (Cost=2 Card=579 Bytes=2316)
8 4 TABLE ACCESS (BY INDEX ROWID) OF 'T_HUB_CONTROL_TR
ADE_HDR' (Cost=1 Card=1 Bytes=12)
9 8 INDEX (UNIQUE SCAN) OF 'T_HUB_CONTROL_TRADE_HDR_
PK' (UNIQUE)
10 3 PARTITION RANGE* (ALL) :Q804383
001
11 10 PARTITION LIST* (ALL) :Q804383
001
12 11 TABLE ACCESS* (FULL) OF 'T_HUB_TRD_MAIN' (Cost=5 :Q804383
9002 Card=84630120 Bytes=2962054200) 001
13 2 INDEX* (RANGE SCAN) OF 'STG_TRD_SWAP_CF_PK' (UNIQUE) ( :Q804383
Cost=3 Card=1) 001
1 PARALLEL_COMBINED_WITH_CHILD
2 PARALLEL_TO_SERIAL SELECT /*+ ORDERED NO_EXPAND USE_NL(A2) INDE
X(A2 "STG_TRD_SWAP_CF_PK") */ A1.C0,
3 PARALLEL_COMBINED_WITH_PARENT
4 PARALLEL_FROM_SERIAL
10 PARALLEL_COMBINED_WITH_PARENT
11 PARALLEL_COMBINED_WITH_PARENT
12 PARALLEL_COMBINED_WITH_PARENT
13 PARALLEL_COMBINED_WITH_PARENT

Find the Wait events for an objects.

Hi Gurus.
I need you help to find out the wait events for a particular table and index when batch export job running from the application. I have done some work around to to find out, but i am not able to figure out the issue or what are the wait events. i am working on linux 4node rac 11gR2.
Below are the steps i have done.
1. find object_id for a table finding the wait events to that object_id.
SYS@ccmintpt1 SQL>select data_object_id from dba_objects where object_name='ACCOUNT_DETAIL_DENORM';
DATA_OBJECT_ID
82646
88518
84184
SYS@ccmintpt1 SQL>select w.sid,w.event,w.wait_class,w.wait_class# from gv$session s,gv$session_wait w where s.row_wait_obj#=82646;
no rows selected
SYS@ccmintpt1 SQL>select w.sid,w.event,w.wait_class,w.wait_class# from gv$session s,gv$session_wait w where s.row_wait_obj#=88518;
no rows selected
SYS@ccmintpt1 SQL>select w.sid,w.event,w.wait_class,w.wait_class# from gv$session s,gv$session_wait w where s.row_wait_obj#=84184;
no rows selected
2. find the object id for the index of that table and finding the wait events to that object_id.
SYS@ccmintpt1 SQL>select data_object_id from dba_objects where object_name='XAK2ACCOUNT_DETAIL_DENORM';
DATA_OBJECT_ID
88655
SID EVENT WAIT_CLASS WAIT_CLASS#
1 rdbms ipc message Idle 6
2 heartbeat monitor sleep Idle 6
3 rdbms ipc message Idle 6
4 wait for unread message on broadcast channel Idle 6
6 SQL*Net message from client Idle 6
7 SQL*Net message from client Idle 6
8 SQL*Net message from client Idle 6
9 SQL*Net message from client Idle 6
10 SQL*Net message from client Idle 6
11 SQL*Net message from client Idle 6
12 SQL*Net message from client Idle 6
13 SQL*Net message from client Idle 6
1876 SQL*Net message from client Idle 6
1877 VKTM Logical Idle Wait Idle 6
1878 rdbms ipc message Idle 6
1879 rdbms ipc message Idle 6
1880 rdbms ipc message Idle 6
1881 SQL*Net message from client Idle 6
3200 SQL*Net message from client Idle 6
3210 SQL*Net message from client Idle 6
3212 db file sequential read User I/O 8
3213 SQL*Net message from client Idle 6
3214 SQL*Net message from client Idle 6
3216 SQL*Net message from client Idle 6
3751 rdbms ipc message Idle 6
3752 gcs remote message Idle 6
3754 rdbms ipc message Idle 6
3756 SQL*Net message from client Idle 6
3757 SQL*Net message from client Idle 6
1326 SQL*Net message from client Idle 6
1876 Streams AQ: waiting for time management or cleanup tasks Idle 6
1877 VKTM Logical Idle Wait Idle 6
1878 rdbms ipc message Idle 6
1879 rdbms ipc message Idle 6
1880 rdbms ipc message Idle 6
1882 SQL*Net message from client Idle 6
3751 rdbms ipc message Idle 6
3752 gcs remote message Idle 6
3754 rdbms ipc message Idle 6
3756 rdbms ipc message Idle 6
3758 SQL*Net message from client Idle 6
3759 PX Deq: Execution Msg Idle 6
3200 SQL*Net message from client Idle 6
3210 SQL*Net message from client Idle 6
3212 db file sequential read User I/O 8
3213 SQL*Net message from client Idle 6
3214 SQL*Net message from client Idle 6
3216 SQL*Net message from client Idle 6
3751 rdbms ipc message Idle 6
3752 gcs remote message Idle 6
3754 rdbms ipc message Idle 6
3756 SQL*Net message from client Idle 6
3757 SQL*Net message from client Idle 6
3786 SQL*Net message from client Idle 6
3787 SQL*Net message from client Idle 6
1 heartbeat monitor sleep Idle 6
2 wait for unread message on broadcast channel Idle 6
314 rdbms ipc message Idle 6
315 Streams AQ: qmn coordinator idle wait Idle 6
627 pmon timer Idle 6
628 rdbms ipc message Idle 6
629 Streams AQ: waiting for messages in the queue Idle 6
940 Streams AQ: waiting for time management or cleanup tasks Idle 6
941 VKTM Logical Idle Wait Idle 6
942 rdbms ipc message Idle 6
1253 rdbms ipc message Idle 6
1254 rdbms ipc message Idle 6
1256 Space Manager: slave idle wait Idle 6
1566 DIAG idle wait Idle 6
1567 rdbms ipc message Idle 6
1568 Streams AQ: qmn slave idle wait Idle 6
1879 rdbms ipc message Idle 6
1880 smon timer Idle 6
1881 rdbms ipc message Idle 6
2192 PING Idle 6
2193 rdbms ipc message Idle 6
2194 rdbms ipc message Idle 6
2505 rdbms ipc message Idle 6
2506 rdbms ipc message Idle 6
2818 rdbms ipc message Idle 6
2819 rdbms ipc message Idle 6
2821 PX Deq: reap credit Other 0
3131 DIAG idle wait Idle 6
3132 jobq slave wait Idle 6
3444 rdbms ipc message Idle 6
3445 jobq slave wait Idle 6
3757 ges remote message Idle 6
3758 rdbms ipc message Idle 6
3759 VKRM Idle Idle 6
4070 gcs remote message Idle 6
4072 rdbms ipc message Idle 6
4383 gcs remote message Idle 6
4385 PX Deq: Execution Msg Idle 6
4696 rdbms ipc message Idle 6
4697 rdbms ipc message Idle 6
1 rdbms ipc message Idle 6
2 heartbeat monitor sleep Idle 6
3 rdbms ipc message Idle 6
4 wait for unread message on broadcast channel Idle 6
6 SQL*Net message from client Idle 6
From this output, what are the waits events i need to take into consideration.
Is this the right approach to follow?
Please let me know.
Thanks in advance.

user13162661 wrote:
Hi Gurus.
I need you help to find out the wait events for a particular table and index when batch export job running from the application. I have done some work around to to find out, but i am not able to figure out the issue or what are the wait events. i am working on linux 4node rac 11gR2.
Below are the steps i have done.
1. find object_id for a table finding the wait events to that object_id.
SYS@ccmintpt1 SQL>select data_object_id from dba_objects where object_name='ACCOUNT_DETAIL_DENORM';
DATA_OBJECT_ID
82646
88518
84184
SYS@ccmintpt1 SQL>select w.sid,w.event,w.wait_class,w.wait_class# from gv$session s,gv$session_wait w where s.row_wait_obj#=82646;
no rows selected
SYS@ccmintpt1 SQL>select w.sid,w.event,w.wait_class,w.wait_class# from gv$session s,gv$session_wait w where s.row_wait_obj#=88518;
no rows selected
SYS@ccmintpt1 SQL>select w.sid,w.event,w.wait_class,w.wait_class# from gv$session s,gv$session_wait w where s.row_wait_obj#=84184;
no rows selected
2. find the object id for the index of that table and finding the wait events to that object_id.
SYS@ccmintpt1 SQL>select data_object_id from dba_objects where object_name='XAK2ACCOUNT_DETAIL_DENORM';
DATA_OBJECT_ID
88655
SID EVENT WAIT_CLASS WAIT_CLASS#
1 rdbms ipc message Idle 6
2 heartbeat monitor sleep Idle 6
3 rdbms ipc message Idle 6
4 wait for unread message on broadcast channel Idle 6
6 SQL*Net message from client Idle 6
7 SQL*Net message from client Idle 6
8 SQL*Net message from client Idle 6
9 SQL*Net message from client Idle 6
10 SQL*Net message from client Idle 6
11 SQL*Net message from client Idle 6
12 SQL*Net message from client Idle 6
13 SQL*Net message from client Idle 6
1876 SQL*Net message from client Idle 6
1877 VKTM Logical Idle Wait Idle 6
1878 rdbms ipc message Idle 6
1879 rdbms ipc message Idle 6
1880 rdbms ipc message Idle 6
1881 SQL*Net message from client Idle 6
3200 SQL*Net message from client Idle 6
3210 SQL*Net message from client Idle 6
3212 db file sequential read User I/O 8
3213 SQL*Net message from client Idle 6
3214 SQL*Net message from client Idle 6
3216 SQL*Net message from client Idle 6
3751 rdbms ipc message Idle 6
3752 gcs remote message Idle 6
3754 rdbms ipc message Idle 6
3756 SQL*Net message from client Idle 6
3757 SQL*Net message from client Idle 6
1326 SQL*Net message from client Idle 6
1876 Streams AQ: waiting for time management or cleanup tasks Idle 6
1877 VKTM Logical Idle Wait Idle 6
1878 rdbms ipc message Idle 6
1879 rdbms ipc message Idle 6
1880 rdbms ipc message Idle 6
1882 SQL*Net message from client Idle 6
3751 rdbms ipc message Idle 6
3752 gcs remote message Idle 6
3754 rdbms ipc message Idle 6
3756 rdbms ipc message Idle 6
3758 SQL*Net message from client Idle 6
3759 PX Deq: Execution Msg Idle 6
3200 SQL*Net message from client Idle 6
3210 SQL*Net message from client Idle 6
3212 db file sequential read User I/O 8
3213 SQL*Net message from client Idle 6
3214 SQL*Net message from client Idle 6
3216 SQL*Net message from client Idle 6
3751 rdbms ipc message Idle 6
3752 gcs remote message Idle 6
3754 rdbms ipc message Idle 6
3756 SQL*Net message from client Idle 6
3757 SQL*Net message from client Idle 6
3786 SQL*Net message from client Idle 6
3787 SQL*Net message from client Idle 6
1 heartbeat monitor sleep Idle 6
2 wait for unread message on broadcast channel Idle 6
314 rdbms ipc message Idle 6
315 Streams AQ: qmn coordinator idle wait Idle 6
627 pmon timer Idle 6
628 rdbms ipc message Idle 6
629 Streams AQ: waiting for messages in the queue Idle 6
940 Streams AQ: waiting for time management or cleanup tasks Idle 6
941 VKTM Logical Idle Wait Idle 6
942 rdbms ipc message Idle 6
1253 rdbms ipc message Idle 6
1254 rdbms ipc message Idle 6
1256 Space Manager: slave idle wait Idle 6
1566 DIAG idle wait Idle 6
1567 rdbms ipc message Idle 6
1568 Streams AQ: qmn slave idle wait Idle 6
1879 rdbms ipc message Idle 6
1880 smon timer Idle 6
1881 rdbms ipc message Idle 6
2192 PING Idle 6
2193 rdbms ipc message Idle 6
2194 rdbms ipc message Idle 6
2505 rdbms ipc message Idle 6
2506 rdbms ipc message Idle 6
2818 rdbms ipc message Idle 6
2819 rdbms ipc message Idle 6
2821 PX Deq: reap credit Other 0
3131 DIAG idle wait Idle 6
3132 jobq slave wait Idle 6
3444 rdbms ipc message Idle 6
3445 jobq slave wait Idle 6
3757 ges remote message Idle 6
3758 rdbms ipc message Idle 6
3759 VKRM Idle Idle 6
4070 gcs remote message Idle 6
4072 rdbms ipc message Idle 6
4383 gcs remote message Idle 6
4385 PX Deq: Execution Msg Idle 6
4696 rdbms ipc message Idle 6
4697 rdbms ipc message Idle 6
1 rdbms ipc message Idle 6
2 heartbeat monitor sleep Idle 6
3 rdbms ipc message Idle 6
4 wait for unread message on broadcast channel Idle 6
6 SQL*Net message from client Idle 6
From this output, what are the waits events i need to take into consideration.
Is this the right approach to follow?
Please let me know.
Thanks in advance.what actual problem are you trying to solve?
post SQL & results that have you concerned about wait events

What is "KJC: Wait for msg .." wait event in 10g??

Hi, all.
The database is 2 node RAC database (10.2.0.2.0)
on 32-bit windows 2003 EE SP1.
I found "KJC: Wait for msg sends to complete" wait event in
"Top 5 Timed Event" Section from AWR report.
What is "KJC: Wait for msg sends to complete" wait event??
The following is from UDUMP.
Dump file d:\oracle\product\10.2.0\admin\rac\udump\rac2_ora_5656.trc
Mon Sep 24 00:04:40 2007
ORACLE V10.2.0.2.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Real Application Clusters, OLAP and Data Mining options
Windows Server 2003 Version V5.2 Service Pack 1
CPU : 4 - type 586, 2 Physical Cores
Process Affinity : 0x00000000
Memory (Avail/Total): Ph:5278M/8190M, Ph+PgF:6596M/10041M, VA:316M/2047M
Instance name: rac2
Redo thread mounted by this instance: 2
Oracle process number: 64
Windows thread id: 5656, image: ORACLE.EXE (SHAD)
*** 2007-09-24 00:04:40.156
*** ACTION NAME:() 2007-09-24 00:04:40.156
*** MODULE NAME:(OEM.SystemPool) 2007-09-24 00:04:40.156
*** SERVICE NAME:(RAC.world) 2007-09-24 00:04:40.156
*** CLIENT ID:() 2007-09-24 00:04:40.156
*** SESSION ID:(486.53) 2007-09-24 00:04:40.156
IPCSendMsg: could not initiate send on conn 0x5b0d3e98 to node [rac1 : 696 : 3996 : 359937], err 10054
IPCGetRequestInfo: failed a request rqh(0x5b060db8), type(6), status(2), bytes(0)
Thanks and Regards.
Message was edited by:
user507290
Message was edited by:
user507290

This might have something to do with bug 5075434 - Small performance overhead in RAC (waits for "KJC: Wait for msg sends to complete").
Check metalink for further details.

PX Deq Credit: send blkd wait event

Similar Messages

Maybe you are looking for