Abdul, There was once a whitepaper describing some scalability testing done with Oracle EBS on a RAC cluster. It showed that as far as scalability goes, the two-to-three node addition didn't yield as much scalability increase as the three-to-four node addition and all other node additions beyond that. I did a quick look, but couldn't find it. In the case of that particular study, this "dip" in scalability (though it was still an increase in overall scalability/throughput) was directly related to the way that RAC's global cache is managed. In any case where a block is cached in another instance, there are three parties involved: the requestor, the holder, and the global resource master for the requested block. In a two-node cluster, two of these three parties are the same instance and therefore the messaging between them is very fast. When a third node is added, there's a statistical probability that these three parties will involve all three instances for a significant portion of the occurrences of this situation. In the case where three instances are involved, the communications take longer since all messaging has to cross the interconnect. That is a long explanation, but may be applicable to some extent in your case. If your application causes the database to perform a lot of interconnect messaging (most likely related to global cache requests), then this may be part of your issue. Statistics are kept on how many block transfers are requested and successful, so it'd be interesting to identify those numbers for your test scenario while varying the number of nodes. On the other hand, it could be something completely unrelated :). That's the wonderful, magical world that is RAC! Dan A Ebadi wrote: -- //www.freelists.org/webpage/oracle-l |