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

"Ian Turner" <iturner1_at_yahoo.com> wrote in message news:d6ftjp$94l$1_at_lore.csc.com...
> 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
>>
>
>

As Gopalakrishnan points out, the critical limit it three nodes. In fact you get a clue from the 10g wait events which list : '2 way cache fusion' and '3 way cache fusion' and don't go above that.

The worst case scenario is:

    Node A says to Node B

        I want block X, you are the directory controller for X     Node B says to node C

        You have block X, give it to node A     Node C says to node A

        Here is the block

    Asynchronously, C and A confirm to X that     the block has been sent and received.

One warning - someone else made the comment that the manuals say "if is scales on one node it will scale on RAC". What the manuals actually says is "if it won't scale on one node it won't scale on RAC".

-- 
Regards

Jonathan Lewis

http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ

http://www.jlcomp.demon.co.uk/seminar.html
Public Appearances - schedule updated April 5th 2005