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

Question

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.

Answer 1

>
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