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_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
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_at_x.washington.edu
(replace x with u to respond)
Received on Wed May 18 2005 - 13:36:02 CDT
