Re: Parallel query on when it's not supposed to be (?)
- From: Steve Rospo <srospo@xxxxxxxxxxxxx>
- To: Mark Richard <mrichard@xxxxxxxxxxxxxxxxx>
- Date: Wed, 15 Sep 2004 09:31:37 -0700 (PDT)
I'm with Mark. If you're seeing stuff like "parallel execution dequeue
wait" all you're seeing is a wait for all of the parallel slaves do
actually do all (most) of the work. I don't think the calling session
really has all that much to do during a query that get's parallelized
so it's pretty easy for things like this to dominate the wait time. I
hesitate to call it "idle" because that makes it too easy to disregard and
Cary and others have shown what can happen there. I'd think of it as more
of a "placeholder" wait and concentrate on what parallel slaves are
waiting on. This is really nasty because parallel execution slaves
persist get reused and I don't know how to deliniate waits in something
like 10046 between different queries, so on a production server I'd have
to do some serious digging.
As for doing more reads, I'm pretty sure PQ bypasses the buffer cache so
in addition to having sufficient CPU capacity you better have IO bandwidth
to spare as well.
S-
On Wed, 15 Sep 2004, Mark Richard wrote:
> I just wanted to pose a question to anyone on the list (particular the wait
> event guru's like Cary)...
>
> Eliminating parallel query because you are seeing waits for it sounds to me
> a little like tuning the BCHR. I can't help but wonder if waiting for a
> parallel query is still the quickest way to get things done? Would killing
> the parallel query effectively move the waits to another category without
> achieving any real gain?
>
> Regards,
> Mark.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
