RE: 64 node Oracle RAC Cluster (The reality of...)

Which instance will write out the next batch of dirty blocks for some
file

Which instance's memory contains the particular read consistent vintage
of a block needed by some client.

If I understand it correctly, you are each very close to a useful
explanation of the order of operation of these two different aspects of
multinode communications requirements in RAC.

In other news, Mladen's note about functional partitioning is of course the
best way to design systems for RAC. Oracle's marketing point is not that it
is not good to functionally partition, just that you don't HAVE TO re-write
your applications.

I am failing to connect your thoughts. If there are n number of nodes,
the resources will be mastered at n number of nodes, thus reducing the
contention for mastership (okay,, there is nothing called contention
for mastership, I am just thinking theoritically) and this will help
in getting required ownership transfers faster as one instance will
have limited number of resources. In crude terms we can compare this
with multiple freelists.

Btw, dynamic remastering does not work at block level. They work at
file level and/or file level/object level.

On 6/21/05, Connor McDonald <mcdonald.connor_at_gmail.com> wrote:
> I haven't thought this through much, but assuming clients are> connecting to instances at "random", then isn't the probability of a> instance requring a block for which it is already the holder approx> 1/n, where n is the number of the nodes. So as the node count rises,> you'd get a reduced likelihood of "success" ?>> I suppose dynamic remastering is meant to assist with this as well.>> Connor>> On 6/21/05, K Gopalakrishnan <kaygopal_at_gmail.com> wrote:> > Raj:> >> > There won't be technically any differnt from 3 node to 64 node as in> > RAC a maximum of 3 parties involved in ANY resource management> > (Master-holder-requester) . Be it is 3 nodes or 64 nodes or 128 nodes.> >