RE: Parallel query on when it's not supposed to be (?)
- From: "Spears, Brian" <BSpears@xxxxxxxxxxxxxxxxx>
- To: <Mark.Bobak@xxxxxxxxxxxxxxx>, <mrichard@xxxxxxxxxxxxxxxxx>, <janine@xxxxxxxxxx>
- Date: Wed, 15 Sep 2004 09:39:14 -0400
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Bobak, Mark
Sent: Wednesday, September 15, 2004 1:42 AM
To: mrichard@xxxxxxxxxxxxxxxxx; janine@xxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
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@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 =
=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@xxxxxxxxxx To: =3D
oracle-l@xxxxxxxxxxxxx
=3D
=3D20
> cc:
=3D
=3D20
Sent by: Subject: Parallel query
=3D
on when it's not supposed to be (?) =3D20
oracle-l-bounce@fr
=3D
=3D20
eelists.org
=3D
=3D20
=20
=3D
=3D20
=20
=3D
=3D20
15/09/2004 05:58
=3D
=3D20
Please respond to
=3D
=3D20
janine
=3D
=3D20
=20
=3D
=3D20
=20
=3D
=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
--
//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 deliver
=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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
