RE: Parallel query on when it's not supposed to be (?)
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxxxxx>
- To: <mrichard@xxxxxxxxxxxxxxxxx>, <janine@xxxxxxxxxx>
- Date: Wed, 15 Sep 2004 01:42:10 -0400
Mark,
Well, I am far, far away from Mr. Milsap's "guru" status, however, my =
take
on it is:
PQ is just another tool in the toolbox. Depending on the application =
and/or
environment, it may be a boon, or it may be the death of you. In a =
typical
multi-user OLTP environment, PQ can kill you. It will starve you of =
system
resources (likely CPU and I/O) and will cause your system to slow to a =
crawl.=20
That's because you have a finite number of CPUs, and each PQ query =
starts
multiple, concurrently executing, PQ slaves. Even if you have a really =
big
SMP box, say 64 CPUs, consider that with parallel_max_servers set =
sufficiently
high, you could essentially kill the box with 10 queries, each w/ a =
parallel
degree of 5. (That's more likely to be 100 PQ slaves than 50, by the =
way.)
Also, consider that there's overhead involved w/ PQ, in terms of slave=20
coordination, which will chew additional CPU.
In the case of a data warehouse, where, for example, you're aggregating
across a huge (possibly partitioned) table, or perhaps you're running =
some
analytic functions on said table, PQ may be a boon. Particularly if =
there=20
are few users of the data warehouse, and they are not all running PQ =
queries
concurrently, PQ may be just the solution.
Bottom line: If you need an answer fast and you've got resources to
spare, then PQ may be the answer for you. Especially if you're in a=20
situation where SQL tuning isn't going to buy you anything, PQ may be
the answer. But watch the resource consumption, and never in a high=20
concurrency multi-user environment.
-Mark
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Mark Richard
Sent: Tue 9/14/2004 10:03 PM
To: janine@xxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Parallel query on when it's not supposed to be (?)
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.
=
=20
Janine A Sisk =
=20
<janine@xxxxxxxxxx To: =
oracle-l@xxxxxxxxxxxxx =
=20
> cc: =
=20
Sent by: Subject: Parallel query =
on when it's not supposed to be (?) =20
oracle-l-bounce@fr =
=20
eelists.org =
=20
=
=20
=
=20
15/09/2004 05:58 =
=20
Please respond to =
=20
janine =
=20
=
=20
=
=20
[snip]
BTW, the reason I care about this is that I'm trying to tune the
production server and a fair number of waits associated with parallel
query are showing up in the statspack report. Since parallel query is
not supposed to be turned on there either, I started looking into it
and found that both systems are exhibiting this bizarre (to me, anyway)
behavior.
Can anyone a) explain what the heck is going on here and b) tell me how
to drive a stake through the heart of parallel query on this system?
thanks,
janine
--
//www.freelists.org/webpage/oracle-l
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>=
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Privileged/Confidential information may be contained in this message.
If you are not the addressee indicated in this message (or responsible =
for delivery of the message to such person), you may not copy or deliver =
this message to anyone.
In such a case, you should destroy this message and kindly notify the =
sender by reply e-mail or by telephone on (03) 9612-6999 or (61) 3 =
9612-6999.
Please advise immediately if you or your employer does not consent to =
Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this message that do not =
relate to the official business of Transurban Infrastructure =
Developments Limited and CityLink Melbourne Limited shall be understood =
as neither given nor endorsed by them.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>=
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
