Re: PX Deq Credit: send blkd

From: Charles Schultz <>
Date: Fri, 29 Aug 2008 10:06:17 -0500
Message-ID: <>

I agree, and I would love to know how to get the best bang for the buck. Doug Burn's excellent "Suck it Dry <>" article goes a long way to explain things, but I still find it hard to really pin my CPU near 100% (in a healthy, good way *grin*) when doing stuff like massive index creates. Even if I distribute my load across many disk spindles and account for memory, etc.

On Fri, Aug 29, 2008 at 9:51 AM, Martin Klier <> wrote:

> Hi list,
> I've got massive wait events named "PX Deq Credit: send blkd". As far as
> I know, that's a parallel query issue, a producer is faster then the
> consumer. But thats a textbook explanantion I simply don't understand.
> The obvious option, to increase PARALLEL_EXECUTION_MESSAGE_SIZE, does
> not fit since it's set to the (x86_64) architecture's maximum, 64k.
> The system is rather capable, and CPU load is less than 30%, disk IO
> around 100MB/s, the underlying ASM diskgroups have been successfully
> tested with nearly 1GB/s.
> The query in question is a huge MERGE statement with APPEND PARALLEL
> hints, a little abstracted form here:
> <fields>
> <other fields>
> from <likewise select again>))
> It comes from a warehouse builder application by oracle, and I have no
> clue if there is another SQL solution, and my question does not touch
> this aspect: I've got no chance to change this at the moment, and if, I
> am no SQL developer.
> But I'd like to know for improving my personal knowledge and for further
> issues, how I can track down the wait event (PX Deq Credit: send blkd)
> to a root cause, and maybe, avoid it.
> Any chance? :)
> Thanks in Advance!
> Martin Klier
> --
> Usn's IT Blog for Linux, Oracle, Asterisk
> --

Charles Schultz

Received on Fri Aug 29 2008 - 10:06:17 CDT

Original text of this message