RAC vs SMP for small EBS shop

From Susan:  

Our group is deliberating on the value of having RAC versus the impact of the added complexity.  We have a relatively small implementation of eBus running AP and GL.  The system is generally only needed on a Mon-Fri 8 am – 5pm basis but in the case of failure we need to be back up in 24 hours or less. 

  Our dba’s are not experienced with a RAC implementation and they do all our patches for the database and application.  We have a separate vendor who supports the infrastructure and network.  The vendor is recommending RAC.

  Can you share on your thoughts on why we would versus why not to consider RAC?

My Response:

I have seen two common hardware mistakes in small organizations, the use of RAC and Oracle Virtual Machines. There’s nothing wrong with either, but OVM has problems with the way most companies architect the VM servers.


RAC is the only way to recover your user’s sessions and continue without a hiccup and even with a slight hiccup the users can just login again. This is nice. However, the maintenance will require at least one additional person that knows RAC, RMAN and ASM, very well and a few more people that are learning. RAC is not a very good solution for scalability with EBS because EBS was not built for RAC; the data should partitioned by geo area or module, but because GL uses HR data, it’s hard to separate the data. If you have fast SANs with Snapshot capabilities, you’ll be required to use RMAN for Backup and Recovery, if you use RAC. I’d recommend Snapshots/BCVs with Net App or EMC for fast backup and recovery. With snapshots I can recover my 400 GB db in about 10 minutes. The other alternative is Data Guard. This will provide failover in about 10-15 minutes, but requires more maintenance and bodies, to test and configure. The least human intensive solution is I/O snapshots.

VM vs Standalone servers

I also don’t like OVM, because of the way most shops configure it. Running the Apps Tier and the DB tier on the same physical VM server can cause network waits on the VM network. If the two tiers are running on  separate physical servers they use TCP for communication and everything is fine. The other issue I find is the VM servers are over utilized, and the existing CPUs are over commited. I/O is another major problem, as it’s more difficult to determine/troubleshoot I/O usage, since the I/O is usually shared by many virtual servers.

Standalone Symmetric MultiProcessing Processor (SMP) machines really do offer better performance, but if you have a large datacenter and want to consolidate, OVM offers some very nice features, but I prefer VMWare from EMC. It offers better utilities. Remember R12 can now run the Apps Tier on 64 bit hardware and this is a big advantage when trying to serve more users; this is because the addressable memory in a 64 bit machine is many time larger than the addressable memory in a 32 bit machine.

The OPS techology evolved into RAC, so I’ve been using RAC for about 16+ years. I usually tell small customers to pull this out of their tech stack, because it’s too complicated for their small staff. Not that it can’t be done, but there needs to be a 24 hour uptime requirement (or zero downtime during certain periods) to make RAC necessary.