This content has been marked as final. Show 5 replies
I found partitioning application workloads across instances in RAC clusters using service names and resource plans to work very well, especially in reducing interconnect congestion. One our RAC databases runs on a four node cluster and has about 15 applications accessing different schemas. I have them all using unique service names; so I can localize processing and data access as much as possible for those applications and their workload cycles to specific instances in the cluster.
Oracle has a good introduction white paper here:
The scheme you are considering (service names, not VIPs) should partition the work perfectly. On the positive side, you should find that data objects are (largely) used in only one instance. This will reduce the cache fusion traffic, and resource remastering will result in the objects being mastered by the instance in which they are used. This should reduce your Global Cache wait events (if you have any) hugely. But negatively, you will be disabling RAC's load balancing capabilities.
I would try it.
Chuck1958 wrote:The default algorithm for distributing sessions is LONG (determined by the -j switch of srvctl add service) which is based on session count. The alternative is SHORT, which is either response time or throughput or CPU usage, determined by the -B switch. It sounds as though you might need
We were hoping rac would load balance for us when it was set up but we are not seeing that when during nightly batch processing one node spikes to 100% cpu and the other stays below 10. How exactly does the load balancing work? Does it consider cpu or is it purely based on the number of sessions?
-j short -B none
which should balance new sessions according to CPU utilization.