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

Similar Messages

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 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

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 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" , 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

"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 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.

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) ?

Script getting hang while trying to execute update command in python using cx_oracle

Hi All,
My script is getting hang while executing below script and it is not throwing any error.
TEMP_PROD_cur=TEMP_PROD_schema_conn.cursor()
sql="update APP_DB_CONNECT set DRIVER=:driver,URL=:url where APPNAME=:appname and CONNECT_NAME=:connect_name"
TEMP_PROD_cur.execute(sql,{'driver':driver_name,'url':jdbc_url,'appname':app_name,'connect_name':connect_name})
TEMP_PROD_schema_conn.commit()
I tried several ways to prepare update statement to execute but the script is getting hang in all the ways.
Please help to resolve this issue.

There's not enough info provided to be able to tell what's going on. You can find online ways to troubleshoot Oracle lock issues - if this is what you are experiencing.

After having iso7 my phone get hanged while answering/calling ?

after having iso7 my phone get hanged while answering/calling ?

Hi varinder22,
If you haven't already done so, you may want to restart or reset the iPhone:
iPhone, iPad, iPod touch: Turning off and on (restarting) and resetting
http://support.apple.com/kb/HT1430
If the above does not resolve your issue, the next best step will be to restore your iPhone using a computer with iTunes. Please be sure to backup your iPhone first.
Choosing an iOS backup method (Should I use iTunes or iCloud to back up my iOS device?)
http://support.apple.com/kb/HT5262
iTunes: Restoring iOS software
http://support.apple.com/kb/HT1414
Thanks,
Matt M.

Getting error while refreshing the Webi report

Hi Guys,
I am getting error, while refreshing Webi reports. Error like:
A database error occured. The database error text is: Error in MDDataSetBW.GetCellData. Time limit exceeded.. (WIS 10901)
Could anyone please reply.
Regards,

Hi,
If it's not the universe limits, then I think you've hit the "MDX result contains too many cells" (more than 1million) problem.
So, I suspect a long running query, no filters/variable restrictions, and You've probably got a dump in ST22.
I don't know what BW you have, but if it is BW 7, do you have Enhancement Pack 01 and SP05<->10 ?
You should check out all the latest corrections from component BW-BEX-OT-MDX
the final proof of the pudding would be to enable MDA / SOFA log , capture the MDX SELECT statement and test it in BW MDXTEST - i bet you get the same error there.
regards,
H

Berkeley DB JE is getting hanged while calling environment sync method.

Hi,
I am developing an application in Java and I am using JE edition of Berkeley. I am facing an issue, during shutdown operation I am calling syn method of EntityStore class and Environment class.
The EntityStore.sync() is getting completed but during executing of Environment.sync() the control is not coming out of this statement. Below is the code that I am using to perform sync operation.
if (myEnv != null) {
try {
entityStore.sync(); //Calling sync method of Entity Store Class.
log.error("Finished Syncing of Entity Store");
myEnv.sync(); // Calling Sync method of Environment Class. Control is not coming out of this sync call.
log.error("Finished Syncing of Environment");
} catch (DatabaseException dbe) {
log.error("DataBase exception duing close operation ",dbe);
} catch (IllegalStateException ie) {
logger.fatal("Cursor not closed: ", ie);
During my unit testing I was changing system date and perfoming some db operation. While I during down the application the the above code gets executed but the system is getting hanged and control is not coming out of Environment sync method call. Can some one tell why the sync is causing the system to hang.
Thanks in advance.

Hello,
You did not mention the version of BDB JE. In any case for BDB JE questions the correct forum is at:
Berkeley DB Java Edition
Thanks,
Sandra

System is getting hanged while creating Adobe Form Layout

Hello,
I have Adobe Lifecycle Designer and Adobe Document Service Installed on our server, i have created Adobe form interface in transaction SFP and then a new form created with this interface passing the parameter carrid.
While creating from layout, through library section I used Text function, as I drag and drop text in to the layout, system is getting hanged everytime with message 1.275 bytes transferred.
Gurus please help me to understand this error.
Thanks,
Avinash

Get Adobe life cycle designer updated vesrion.
Also check your desktop/laptop if it has good RAM .
Adobe is quite fat application which depend upon ur sys prefomanc.
Hope this will help.
Thanks Dhiraj.

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

Similar Messages

Maybe you are looking for