Oracle RAC, what Oracle does not tell you.

Recently in one of my customers, executive management wants to deploy Oracle RAC everywhere, The enterprise architecture group armed with a bunch of marketing material and sales speeches are afraid to confront those decisions, furthermore they have decided to embrace them.

Although I love RAC technology there are several factors you need to take into consideration before jumping into the wagon.

- RAC is very , very complicated, you need high skilled dedicate personnel to maintain this.
- Not every single application is RAC aware.
- RAC does not improve your performance, RAC offers you high availability and scalability.

My advice is to not to use RAC at least your really needed, the degree of complexity and the
increase of maintenance is such that your ROI have to really call for it. A good way to determinate this is to ask yourself, how much money is going to lose the company because the database went down for 15 minutes.

If your application is not designed for RAC, meaning that is has transaction isolation and benefits from parallelism then you can experience significant performance degradation due to block contention (block busy waits). In one of the test we performed we found that an application that is not RAC aware got 45% performance degradation when deployed on RAC using load balance across 2 nodes.

There is this big misconception that if you need more power you add nodes to a RAC cluster, if your application can't escalate vertically, it is not going to escalate horizontally either, furthermore if the application is not RAC aware your performance will be degraded exponentially with each node you add to the cluster.

Despite everything I mention above RAC is an excellent architecture for high availability and scalability as long as your application allows for it.