Why don't applications which switch to Oracle Real Application Server (RAC) simply scale-up as expected? Generally you will find that a single instance database with a baseline performance of 100% under heavy load does not give you the expected 200% when you add a second server such as you would in a RAC environment. You will probably find that performance falls way short of expectations with an actual reduction (under the same heavy load) to 70%. This is often the reason why a twin-server RAC is configured to run in Hot-Standby thus only utilizing one server until a fail-over becomes necessary. But that means wasting half of your resources most of the time as with a HAC solution. So the question is, can you get a higher performance whilst retaining high availability thus not having to pay off one against the other? The answer is yes. But you don't get it by chance you have to be aware of some important issues.
The first and most important aspect is we must have some kind of logical separation within our application. That could by online and batch services or private and business services or anything else which gives you the ability to differentiate the work to be done. If we find something which breaks-down even lower say to 10 or 20 aspects that's ok too because we can simply group them together as needed. What we are aiming to achieve is to specifically map the work to the number of nodes we have in our Real Application Cluster and we don't want to leave that to chance. We want to direct certain work to specific nodes and not have the scan-listener do its standard load-balancing of distributing connections across the available nodes. That in itself can get a bit tricky to control but there a various ways of achieving it. The second and most important thing is to try and make sure the data buffers our work needs are held by that node. Whilst data not held on that node will be obtained from another node via interconnect or via direct-io we want to avoid that most of the time. In order to achieve that we should have our tables partitioned by our logical separation criteria. Although that sounds pretty simple it can be difficult to implement but the rewards are stunning.
We should find that we get very close to the expected 200% performance increase. If we later need to handle an even higher workload we should be able to scale-up to 3 or 4 database nodes and divide our logical workload accordingly. The key to success is getting our table partitions divided in line with our logical workload. The partitions (and their buffers) will be mastered on the node where the most work is being done. It may sound like we are forcing data blocks to be held on specific nodes but that is not really true. We are preferring data to be held where it is currently needed. If a node is added or removed the data is simply relocated to a different node. What we don't want at all costs is for hot-buffers to be constantly parsed between nodes. Whilst the exchanging of data across the interconnect is very fast, hot-buffers which are dirty (ie. have pending commits) will be synced to storage prior to the handing over of the block to the other instance. Instead of an interconnect block access on an old block (which is not dirty) that takes maybe 3ms it may take 103ms because the hot-buffer has to be synced to the SAN (costing 100ms) first.
Whilst there are many more standard Oracle features which you can leverage to help scale an application in a RAC environment this is probably the most significant.
The basic paradigm for High Performance RAC development is "Don't leave anything to chance and allways build to scale".
