You probably don't need RAC . . .

For those who actually think that RAC is new it is actually the latest incarnation of what started out life as Oracle Parallel Server. The achilles heel of Parallel Server was block contention between the instances which the database was mounted across, in that the instances would 'ping' the shared disks in order to maintain data integrity. If an instance required a block that was in the buffer cache of another instance, the block would have to be written to disk before the first instance could read the block into it’s own buffer cache, this was termed 'pinging' in Oracle parlance. Thus Oracle always recommended that applications were portioned across instances so as to minimise pinging.

Where RAC differs from Oracle Parallel Server is that it uses high speed inter connects to 'fuse' the buffer caches of all the instances in the cluster together, deemed "cache fushion". Version one of this technology prevented read/write pinging and this arrived in 8i, the full implementation of this technology came along in 9i and with it Oracle heralded near linear scalability.

However a truism of all architectures is that you never completely eliminate a bottleneck, you merely move it around and although RAC in 9i is a far more scalable product than OPS, the bottleneck is now the memory interconnect. Because of this you still need to partition your data in order to achieve the best scalability by minimising buffer cache inter connect traffic.

Those wacky guys at Miracle AS (www.miracleas.dk - wacky because they are the only Oracle consultancy to have their own micro brewery) have written an excellent paper entitled "You probably don't need RAC", refer to :-

http://www.miracleas.dk/WritingsFromMogens/YouProbablyDontNeedRACUSVersion.pdf

this in turn points to other good sources of reference material.

The main things to be aware of with RAC are it's costs :-

1. You need clustered servers, this in turns require system administrators with clustering expertise, I believe that to receive training from Oracle for RAC running under SUN you need to be a SUN certified cluster administrator which costs thousands of pounds in training. And in general the number and competency of your support staff will need to increase.

2. Because the servers share the same disks you need a half decent SAN.

3. Most sensible organisations will require a test environment, so multiply thes costs by two and then of course you may need a development environment.

4. You need Enterprise Edition for partitioning although I think that you may now get RAC free with 10g Standard Edition.

Consider also availability, some people may claim they want RAC to ensure 24 x 7 availability in the event of server failure, however it is not unheard of that you may require :-

• Os upgrade patches.
  
• Firmware upgrades.
  
• Oracle upgrades and patches.
  
• Application upgrades and patches.

Interestingly the paper goes on to say that under certain conditions RAC can revert to OPS type behaviour and Tom Kyte states in one of his answers on Ask Tom that RAC can amplify bad scalability. A presentation recently given on the UKOUG circuit used a partitioning scheme using the instance that inserted rows into tables used in the bench mark as part of the partition key via sys_context('userenv', 'instance') and apparently this worked quite well in bench marks, so obviously RAC is not unlike it's predecessor in that careful consideration has to be given to partitioning your data.