Before Real Application Clusters (RAC) there was Oracle Parallel Server (OPS). Actually, it was Cache Fusion that changed the whole picture and that appeared in OPS with Oracle 8.1.6, but it is Cache Fusion that makes RAC the great product it is today. Before Cache Fusion, OPS had a problem when two different instances needed access to the same data block. OPS had to make sure that the first instance wrote the block contents back to disk before the second instance could read that data. This is known as "disk pinging." Disk pinging could kill an application's performance even though multiple servers were involved in the database cluster. In those days, one way to avoid disk pinging was to segregate the application functionality among the instances in the OPS cluster. So having one instance for OLTP, one for batch, and one for OLAP in your RAC deployment is very similar to the application segregation that DBAs did in the old OPS days. I currently have two systems which we are investigating clustering with RAC. When we do, we will still do something akin to application segregation, but still enjoy other benefits of RAC. So I don't see anything wrong with your approach. Just make sure that you configure your application for Transparent Failover so that when the OLTP instance goes down, OLTP transactions can continue.
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.