| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Parallel query on when it's not supposed to be (?)
Just a confirmation of Mark's comment of starving cpu and resourses. We have a monster HP system with about 20 cpus and we had a large batch that was broken into 14 pieces and run concurrently to meet an SLA. One fellow turn on parallel query ...and well 14 heavy batches hitting the system all at once.. And then all these batches trying to use parallel query brought the batch speed to a crawl. Too many Parallel queries all competing against each other. I think it was a try it and see what happens... Several of us DBA's were confident it was going to be counter productive since they already had parallelized the single batch to 14 little simultaneous batches. It was a payroll run for 100,000 people.
Brian Spears
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Bobak, Mark
Sent: Wednesday, September 15, 2004 1:42 AM
To: mrichard_at_transurban.com.au; janine_at_furfly.net
Cc: oracle-l_at_freelists.org
Subject: RE: Parallel query on when it's not supposed to be (?)
Mark,
Well, I am far, far away from Mr. Milsap's "guru" status, however, my =
=3D
take on it is:
PQ is just another tool in the toolbox. Depending on the application =
=3D
and/or environment, it may be a boon, or it may be the death of you. In
a =3D typical multi-user OLTP environment, PQ can kill you. It will
starve you of =3D system resources (likely CPU and I/O) and will cause
your system to slow to a =3D crawl.=3D20 That's because you have a =
finite
number of CPUs, and each PQ query =3D starts multiple, concurrently
executing, PQ slaves. Even if you have a really =3D big SMP box, say 64
CPUs, consider that with parallel_max_servers set =3D sufficiently high,
you could essentially kill the box with 10 queries, each w/ a =3D =
parallel
degree of 5. (That's more likely to be 100 PQ slaves than 50, by the =
=3D
way.)
Also, consider that there's overhead involved w/ PQ, in terms of
slave=3D20 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 =
=3D
some analytic functions on said table, PQ may be a boon. Particularly
if =3D there=3D20 are few users of the data warehouse, and they are not =
all
running PQ =3D 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=3D20
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=3D20
concurrency multi-user environment.
-Mark
-----Original Message-----
From: oracle-l-bounce_at_freelists.org on behalf of Mark Richard Sent: Tue 9/14/2004 10:03 PM To: janine_at_furfly.net Cc: oracle-l_at_freelists.org 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 =
=3D
wait event guru's like Cary)...
Eliminating parallel query because you are seeing waits for it sounds to
=3D 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 =3D killing the parallel query effectively move the waits to =
another
category =3D without achieving any real gain?
Regards,
Mark.
=20
=3D
=3D20
Janine A Sisk
=3D
=3D20
<janine_at_furfly.net To: =3D
oracle-l_at_freelists.org
=3D20
> cc:
=3D
=3D20
Sent by: Subject: Parallel query
=3D
on when it's not supposed to be (?) =3D20
oracle-l-bounce_at_fr
=3D
=3D20
eelists.org
=3D
=3D20
=3D20
=3D20
15/09/2004 05:58
=3D
=3D20
Please respond to
=3D
=3D20
janine
=3D
=3D20
=3D20
=3D20
[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
-- http://www.freelists.org/webpage/oracle-l <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>> >=3D >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Privileged/Confidential information may be contained in this message. If you are not the addressee indicated in this message (or responsible =3D for delivery of the message to such person), you may not copy or deliverReceived on Wed Sep 15 2004 - 08:35:44 CDT
=3D this message to anyone. In such a case, you should destroy this
message and kindly notify the =3D sender by reply e-mail or by telephone on (03) 9612-6999 or (61) 3 =3D 9612-6999. Please advise immediately if you or your employer does not consent to =3D Internet e-mail for = messages of this kind. Opinions, conclusions and other information in this message that do not =3D relate to the official business of Transurban Infrastructure =3D Developments Limited and CityLink Melbourne Limited shall be understood =3D as neither given nor endorsed by them. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>> >=3D >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l
 |
 |