Don’t use RAC unless you need it

http://www.nocoug.org/Journal/NoCOUG_Journal_201202.pdf

Some people consider RAC more reliable, but in my experience it most certainly is not; there is still a
single point of failure—the storage subsystem—and the complexity of RAC makes it far less bugfree.


In addition, RAC is an option that is purchased in addition to the Enterprise Edition license.


 Buying RAC for two nodes of one processor apiece is usually far more expensive than buying a non-RAC
license for one two-processor box.
 Buying a machine with eight processors will cost less in overall costs than buying four servers with two processors apiece.
 In fact, buying RAC for any number of nodes is more expensive than buying one box that has the same
amount of processing power/memory.
 Your database will run faster on a single box with, say, four processors and 64 G of RAM than it will on four boxes with one processor apiece and 16 G of RAM apiece, and you’ll save on licensing costs as well.


The speed of the network interconnect between machines (used to move blocks between instances in a RAC configuration) is an order of magnitude or more slower than the speed of inter-processor ommunication
on a single machine with multiple processors.


Current CPUs are far, far faster than they have been historically; most database servers today are oversized in terms of processing power. If using the “unlimited users/CPU” license structure, RAC is far more expensive in licensing costs than a single machine with multiple processors.




with today’s high-end hardware, RAC really doesn’t make much sense when viewed in a cost-benefit, accounting-based analysis for most applications.


Some people consider RAC more reliable, but in my experience it most certainly is not; there is still a single point of  failure—the storage subsystem—and the complexity of RAC makes it far less bugfree


 RAC does help protect against CPU/memory/network issues, but it does not  protect against physical or logical storage corruption.


In my experience, the main bottleneck most databases experience is almost never CPU; they are rarely CPU-bound. Instead, they are I/O bound, and in particular IOPS bound (input/output operations per second); that is to say, they are  not limited by the bandwidth of the storage subsystem but  rather by the latency of single-block reads. For this reason,  don’t focus on the disk bandwidth; focus on IOPS. There is o
other program that I know of that can stress storage as much as Oracle at high loads