Re: PX Deq Credit: send blkd
- From: "Charles Schultz" <sacrophyte@xxxxxxxxx>
- To: usn@xxxxxxxxx
- Date: Fri, 29 Aug 2008 10:06:17 -0500
I agree, and I would love to know how to get the best bang for the buck.
Doug Burn's excellent "Suck it Dry <http://oracledoug.com/px.html>" 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 <usn@xxxxxxxxx> 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:
>
> MERGE /* APPEND PARALLEL ("TABLE_A") */
> INTO "WA_FILBU_BEARB"
> USING (SELECT /*+ PARALLEL ("TABLE_B") PARALLEL ("TABLE_B") PARALLEL
> ("TABLE_B") PARALLEL ("TABLE_B") PARALLEL ("TABLE_B")*/
> <fields>
> from (SELECT /*+ PARALLEL ("TABLE_B") PARALLEL ("TABLE_B") PARALLEL
> ("TABLE_B") PARALLEL ("TABLE_B") PARALLEL ("TABLE_B")
> <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
> http://www.usn-it.de
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Charles Schultz
Other related posts:
