Data warehouses often rely on Oracle's parallel query option for scanning large tables quickly, either for reporting or the generation of materialized views. The effectiveness of PQO is tightly integrated with the number of available CPUs, and since RAC is often used to scale horizontally as opposed to vertically (more machines vs. more CPUs), reliance on parallel query can often decrease performance in a RAC environment in comparison to a symmetrical multiprocessor server. In a RAC environment each node must transfer back the data to the PQ coordinator which can cause great bottlenecks that are better managed within a single server. Add in the typical large sort operations of these types of systems, often relying on huge RAM resources found on horizontally scaled single servers, and the problem with a RAC'd data warehouse becomes even greater.
Of course servers have limits and there are systems that require some sort of clustering to support very large user communities regardless of the nature of the database, plus some of these problems can be mitigated with very advanced proactive tuning. But they are the exceptions. We're talking general rules here, and as a general rule I would be hard pressed to recommend RAC for a data warehouse to address performance issues.
I always look at RAC as an availability solution first, as a scalability solution for large OLTP databases second. To consider it for a data warehouse performance solution I would have to be presented a very complex situation where the uniqueness of the system allowed for some sort of benefit that could not be addressed by a single server.
I hope this helps,
Dig Deeper on Oracle database design and architecture
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.