I am being told by my supplier that if my application works okay on a two
nodes Oracle RAC database there is no problem scaling up - to over ten
nodes. Is that true? Are there no contention issues that will appear as
the cluster grows beyond two nodes?

regards

Ian

The Oracle version will be 10g....

I guess my worry is that communication between nodes must expand massively
as the cluster grows - maybe I don't understand the RAC technology properly.

Each node has to communicate via CacheFusion to synchronise inserts,
updates, deletes with all other nodes.

So whilst something operating within a two node cluster a node might be able
to communicate its changes quite adequately with one node - how can you
guarantee its ability to send out the update to 9 other nodes if the cluster
is expanded to 10.

If the communication is point-to-point, e.g. every node in the cluster has
to notify every other node in the cluster of a change, I can't see how
adding more nodes can have an impact on performance.

I assume that is the reason for trying to allocate specific work profiles to
specific nodes so that contention/updates for the same resources are avoided
and communication between the nodes can be slowed (perhaps using the
parameter you mention).

thanks

Ian


"Jesse" <jesjdavis@gmail.com> wrote in message
news:1116421956.327554.26340@f14g2000cwb.googlegro ups.com...
> With the default settings, I wouldn't necessarily agree (whether Oracle
> says it or not) that an app working on a single instance DB would
> definitely scale up to RAC w/o any problems.
>
> There's an important parameter "max_commit_propagation_delay" that be
> default is set to 7 seconds (may be in milli as 7000; I forget).
> Anyway, this is the maximum amount of time that can go by before a
> commit on one node is seen at the other nodes. We have a client-server
> app (developed by a third party; we have the code though) that opens
> three Oracle sessions per app instance (yes, I know; bad design). The
> idea is that one was a read only, one for transactions, etc. Anyway,
> with the setting above, the app may commit a transaction on one node
> and (due to load balancing) read the results of that transaction
> immediately after commital. Because of the delay (again, up to 7
> seconds), the new data wasn't always there. We changed the setting to
> 0 (have not seen a performance hit) and the problem went away.
>
> Eventually, the app (and others) will be redesigned to be more
> RAC-friendly, but for now, we're sticking with the 0 setting.
>
> Now, once you're ok on a two (or more)-node RAC, I would agree that
> scaling up shouldn't be a problem... with one caveat; make sure you've
> got the latest and greatest patchsets, etc. On 9i, there was some
> problem with the DBCA (I think) that had issues with a 5+ node setup
> (don't quote me on this). You didn't mention the version that you were
> considering (9.2.0.x, 10g, etc.).
>
> Jesse
>

Well, according to the Oracle Concepts guide of RAC, if your app works
well on even one node it will scale well with RAC. But I have not
tested this, so I do not know the definitive answer for you. I'm sure
someone else here will. Anyway, if you haven't taken a peek at the
concepts guide, you might want to.

Mike

With the default settings, I wouldn't necessarily agree (whether Oracle
says it or not) that an app working on a single instance DB would
definitely scale up to RAC w/o any problems.

There's an important parameter "max_commit_propagation_delay" that be
default is set to 7 seconds (may be in milli as 7000; I forget).
Anyway, this is the maximum amount of time that can go by before a
commit on one node is seen at the other nodes. We have a client-server
app (developed by a third party; we have the code though) that opens
three Oracle sessions per app instance (yes, I know; bad design). The
idea is that one was a read only, one for transactions, etc. Anyway,
with the setting above, the app may commit a transaction on one node
and (due to load balancing) read the results of that transaction
immediately after commital. Because of the delay (again, up to 7
seconds), the new data wasn't always there. We changed the setting to
0 (have not seen a performance hit) and the problem went away.

Eventually, the app (and others) will be redesigned to be more
RAC-friendly, but for now, we're sticking with the 0 setting.

Now, once you're ok on a two (or more)-node RAC, I would agree that
scaling up shouldn't be a problem... with one caveat; make sure you've
got the latest and greatest patchsets, etc. On 9i, there was some
problem with the DBCA (I think) that had issues with a 5+ node setup
(don't quote me on this). You didn't mention the version that you were
considering (9.2.0.x, 10g, etc.).

Jesse

Ian Turner wrote:
> I am being told by my supplier that if my application works okay on a two
> nodes Oracle RAC database there is no problem scaling up - to over ten
> nodes. Is that true? Are there no contention issues that will appear as
> the cluster grows beyond two nodes?
>
> regards
>
> Ian

That is correct with one caveat. Run a StatsPack and see how the memory
interconnect is being used. If you don't have block contention issues
you should be just fine. If you do ... then address those issues first.
--
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)

Ian Turner wrote:
> The Oracle version will be 10g....
>
> I guess my worry is that communication between nodes must expand massively
> as the cluster grows - maybe I don't understand the RAC technology properly.
>
> Each node has to communicate via CacheFusion to synchronise inserts,
> updates, deletes with all other nodes.
>
> So whilst something operating within a two node cluster a node might be able
> to communicate its changes quite adequately with one node - how can you
> guarantee its ability to send out the update to 9 other nodes if the cluster
> is expanded to 10.
>
> If the communication is point-to-point, e.g. every node in the cluster has
> to notify every other node in the cluster of a change, I can't see how
> adding more nodes can have an impact on performance.
>
> I assume that is the reason for trying to allocate specific work profiles to
> specific nodes so that contention/updates for the same resources are avoided
> and communication between the nodes can be slowed (perhaps using the
> parameter you mention).
>
> thanks
>
> Ian
>
>
> "Jesse" <jesjdavis@gmail.com> wrote in message
> news:1116421956.327554.26340@f14g2000cwb.googlegro ups.com...
>
>>With the default settings, I wouldn't necessarily agree (whether Oracle
>>says it or not) that an app working on a single instance DB would
>>definitely scale up to RAC w/o any problems.
>>
>>There's an important parameter "max_commit_propagation_delay" that be
>>default is set to 7 seconds (may be in milli as 7000; I forget).
>>Anyway, this is the maximum amount of time that can go by before a
>>commit on one node is seen at the other nodes. We have a client-server
>>app (developed by a third party; we have the code though) that opens
>>three Oracle sessions per app instance (yes, I know; bad design). The
>>idea is that one was a read only, one for transactions, etc. Anyway,
>>with the setting above, the app may commit a transaction on one node
>>and (due to load balancing) read the results of that transaction
>>immediately after commital. Because of the delay (again, up to 7
>>seconds), the new data wasn't always there. We changed the setting to
>>0 (have not seen a performance hit) and the problem went away.
>>
>>Eventually, the app (and others) will be redesigned to be more
>>RAC-friendly, but for now, we're sticking with the 0 setting.
>>
>>Now, once you're ok on a two (or more)-node RAC, I would agree that
>>scaling up shouldn't be a problem... with one caveat; make sure you've
>>got the latest and greatest patchsets, etc. On 9i, there was some
>>problem with the DBCA (I think) that had issues with a 5+ node setup
>>(don't quote me on this). You didn't mention the version that you were
>>considering (9.2.0.x, 10g, etc.).
>>
>>Jesse

IIRC Oracle will support up to an 80 node cluster with 10gR1. My
understanding is that this limitation will be removed with 10gR2.
--
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)

The Oracle version will be 10g....

I guess my worry is that communication between nodes must expand massively
as the cluster grows - maybe I don't understand the RAC technology properly.

Each node has to communicate via CacheFusion to synchronise inserts,
updates, deletes with all other nodes.

So whilst something operating within a two node cluster a node might be able
to communicate its changes quite adequately with one node - how can you
guarantee its ability to send out the update to 9 other nodes if the cluster
is expanded to 10.

If the communication is point-to-point, e.g. every node in the cluster has
to notify every other node in the cluster of a change, I can't see how
adding more nodes can have an impact on performance.

I assume that is the reason for trying to allocate specific work profiles to
specific nodes so that contention/updates for the same resources are avoided
and communication between the nodes can be slowed (perhaps using the
parameter you mention).

thanks

Ian


"Jesse" <jesjdavis@gmail.com> wrote in message
news:1116421956.327554.26340@f14g2000cwb.googlegro ups.com...
> With the default settings, I wouldn't necessarily agree (whether Oracle
> says it or not) that an app working on a single instance DB would
> definitely scale up to RAC w/o any problems.
>
> There's an important parameter "max_commit_propagation_delay" that be
> default is set to 7 seconds (may be in milli as 7000; I forget).
> Anyway, this is the maximum amount of time that can go by before a
> commit on one node is seen at the other nodes. We have a client-server
> app (developed by a third party; we have the code though) that opens
> three Oracle sessions per app instance (yes, I know; bad design). The
> idea is that one was a read only, one for transactions, etc. Anyway,
> with the setting above, the app may commit a transaction on one node
> and (due to load balancing) read the results of that transaction
> immediately after commital. Because of the delay (again, up to 7
> seconds), the new data wasn't always there. We changed the setting to
> 0 (have not seen a performance hit) and the problem went away.
>
> Eventually, the app (and others) will be redesigned to be more
> RAC-friendly, but for now, we're sticking with the 0 setting.
>
> Now, once you're ok on a two (or more)-node RAC, I would agree that
> scaling up shouldn't be a problem... with one caveat; make sure you've
> got the latest and greatest patchsets, etc. On 9i, there was some
> problem with the DBCA (I think) that had issues with a 5+ node setup
> (don't quote me on this). You didn't mention the version that you were
> considering (9.2.0.x, 10g, etc.).
>
> Jesse
>

Ian Turner wrote:
> I am being told by my supplier that if my application works okay on a two
> nodes Oracle RAC database there is no problem scaling up - to over ten
> nodes. Is that true? Are there no contention issues that will appear as
> the cluster grows beyond two nodes?
>
> regards
>
> Ian

That is correct with one caveat. Run a StatsPack and see how the memory
interconnect is being used. If you don't have block contention issues
you should be just fine. If you do ... then address those issues first.
--
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)

I believe you right to be cynical. 2 node clusters are definitely a special
case, power of two clusters are more generally a special case. That said
what is wrong with asking them to show you. get an app (or probably a real
benchmark) and compare real throughput and performance over 1 to 10 nodes.


--
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com
"Ian Turner" <iturner1@yahoo.com> wrote in message
news:d6f1r6$6kg$1@lore.csc.com...
>I am being told by my supplier that if my application works okay on a two
>nodes Oracle RAC database there is no problem scaling up - to over ten
>nodes. Is that true? Are there no contention issues that will appear as
>the cluster grows beyond two nodes?
>
> regards
>
> Ian
>

Per the following post by Howard J. Rogers:

http://groups-beta.google.com/group/...6d2a57d387194e

As the number of nodes increase, a solid interconnect (i.e.
low-latency, high bandwidth) becomes more and more important.

Howard also gives a quick summary of Cache Fusion (same post) as
follows:
************
Cache fusion means nothing much more than messages going
back and forth across the interconnect asking 'who is in charge of this

resource' and 'may I have it?", and occasionally the data block itself
getting sent via the same pathway. But there's no 'synchronisation' on
all
of that... just a directory master coordinating serialised access to
the
block.
************

Jesse