Re: Oracle RAC Performance - Two node test provides scaling to 10+nodes?

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_at_gmail.com> wrote in message news:1116421956.327554.26340_at_f14g2000cwb.googlegroups.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
>
Received on Wed May 18 2005 - 12:22:55 CDT