This content has been marked as final. Show 5 replies
vreddy wrote:No it is not. It means a lot more than just that.
Ideally RAC is meant for High Availability.
You can get same performance RAC/Non RAC as long as your SQL statements are tuned to optimum.Untrue. Significantly better performance can be achieved on RAC - as RAC also means scalability.
In RAC it depends on how your services are defined and configured so that cache transfer of blocks across nodes is kept to minimumIncorrect. RAC depends on 3 basic components. The speed (bandwidth and latency) and redundancy of the Interconnect and I/O fabric layers. The performance of the RAC server nodes. These components determines how well RAC performs, scales, how robust and stable it is, and directly impacts high availability too.
The core issue is using RAC correctly and effectively. Not using RAC by minimising cache-to-cache block transfers.
shengjin_wu wrote:Neither. As that would be running old s/w that is soon to become unsupported and dated s/w.
oracle 10g two node rac cluster VS four node rac cluster which is better ?
The correct choice is 11gr2 RAC.
If the servers are exactly the same - then 4 server will be "better" than 2 servers.
Why? Better scalability (provides more CPU cores and more I/O channels). Increased redundancy (2 node failure does not mean loosing the entire 2 node cluster as there are now 4 nodes). Better availability.
That said, part of the decision is what the server h/w will be and what the loads are. If 2 servers suffice in carrying the load, why use 4? Another factor is cost. RAC is typically licensed per core. The more servers, the more cores, the heftier the price tag.
Thus if 2 servers can carry the load, putting 4 servers down would make the solution a lot more expensive that what it could have been. But cost does not change the fact that RAC scales with more servers - you can scale CPU and RAM on a single server, but that does not scale the I/O fabric layer. Which means additional processes running on the additional CPUs and RAM on that server, will contend for the same fixed I/O subsystem, with the existing processes. And that is what makes RAC such an excellent architecture. You can scale all the components - from CPU cores to I/O.