RE: log file sync (now EBS, RAC, PARALLEL_MAX_SERVERS)
Date: Fri, 24 Aug 2012 08:50:36 -0400
Message-ID: <304F58144267C5439E733532ABC9A3A115CA651C_at_USA0300MS02.na.xerox.net>
The idea is to maintain affinity for parallel processes by limiting them to the node from where the (parallel) query was started. This will also help reduce traffic across the interconnect. The concurrent managers will be 'partitioned' so that all connections from a certain Concurrent Processing node are routed to a specific RAC node and would not get load-balanced to multiple RAC nodes.
-----Original Message-----
From: Mark W. Farnham [mailto:mwf_at_rsiz.com]
Sent: Thursday, August 23, 2012 3:11 PM
To: ora_kclosson_at_yahoo.com; Hameed, Amir
Cc: oracle-l_at_freelists.org
Subject: RE: log file sync (now EBS, RAC, PARALLEL_MAX_SERVERS)
Youch!
If you really can't fit your processing need on a single node, then you
usually need to set up application affinity for EBS to fight less with
RAC
architecture. So you probably do not want to allow parallel queries to
cross
nodes. (You might I suppose if you have a blackout period to run certain
jobs against nothing else, the archetype being open GL period, but even
then
it is not a certainty that will run faster on multiple nodes than on a
single node.)
So unless you've got a really good reason you should configure so that parallel queries on EBS systems cannot cross node boundaries.
Next, with the concurrent manager being able to schedule jobs so that
you
can eat up pretty much all the resources on all the nodes, there is a
real
question of overall throughput about whether you want any single job to
run
in parallel ever. (Please notice I wrote "real question" and that a real
world load mix and real world demands for some individual job to
complete
more quickly may mean allowing it to run in parallel justifies
sacrificing
overall throughput. Keeping some broad resource hog out of "prime time"
[if
in this increasingly global world you still have a "prime time"] might
also
justify running some job in parallel even if the consumer does not need
it
in a hurry. This tends to be true of large update batch jobs, so if you
can
"de-heat" the undo for when routine queries are heavier you can reduce
the
total work required to execute the overall load.)
Good luck.
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Kevin Closson
Sent: Thursday, August 23, 2012 1:49 PM
To: Amir.Hameed_at_xerox.com
Cc: oracle-l_at_freelists.org
Subject: Re: log file sync
Now I am working on addressing the "direct path read " event which is
coming
from a standard EBS statement that contains 'parallel' clause without
any
DOP which ends up invoking 144 parallel processes on three RAC nodes
(PARALLEL_MAX_SERVERS is set to 48 on each RAC node).
... Eeek...taming the beast as it were.
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Fri Aug 24 2012 - 07:50:36 CDT