Re: Questions consolidating databases onto RAC Cluster
Date: Thu, 28 Apr 2016 07:04:02 -0600
Message-ID: <57220A42.7060008_at_gmail.com>
On 27/04/2016 2:13 PM, Chris Taylor wrote:
> After doing some research, it appears that common wisdom is to NEVER
> have 2 different RAC databases sharing the same cluster.
>
Even though they conflict, Tom's statement is correct as are the real life examples by the other respondents.
Tom's assertion is should be a maximum of one instance per node. I'll take it one farther, even without RAC, there should be only one instance of Oracle database - and no other resource consuming program running.
The assertions are based on the idea that the resource consumption is not entirely known, with spikes in I/O, memory (PGA) usage, and CPU usage that impact performance and availability. When multiple instances are on a system, there is a randomization in resource consumption that can easily overwhelm the physical infrastructure. Since very few DBAs use the resource management capability to limit consumption, the result is unpredictable.
One additional aspect is tied to high availability in RAC. A node eviction or maintenance bounce will impact multiple instances, where the relationship between instances is based on sharing hardware, not based on application commonality.
On the other hand, in reality these days we find sufficient hardware resource available, with sufficient redundancy and resilience, at a reasonable price point, that resource consumption is not as much a concern as it was 10 or more years ago. Instead, the operations costs - human resources for administration, power per box, physical floor space, air conditioning, etc. - and hardware retirement costs, overwhelm the cost of the hardware resource itself. This has resulted in multi-tenant environments (virtualization, containers, other shared infrastructure environments such as Oracle's CDB capability) becoming more mature, therefore more manageable.
Resource managers, load balancers, and other related technologies - including those found in Oracle database and Exadata - can mitigate the risk of hitting resource limits that impact performance and availability.
Consider what happens if you overcommit resources: a SAN with 100TB of physical disk, and 300TB sparse disk allocation; a host with 192 CPU/1TB RAM but 256 CPUs/4TB RAM requested by the virtual machines on that host. If appropriate controls are not in place, if appropriate automation is not in place, if appropriate resource management handlers are not in place - and configured - there is a risk of things coming tumbling down.
Tom was correct for the assumptions that were valid and predominant at the time that response was written (2009). However, a shift toward resource sharing - as well as a dramatic increase in resources available to be shared (when did TB RAM and 25 core CPUs become available) - was happening at that time, and supporting controls started to be developed to mitigate the issues that come from resource sharing. As long as those controls are understood and used appropriately, and the risk is understood, sharing is becoming 'the common wisdom'.
Things change. Common sense/common wisdom changes when things change. I wish all articles on the internet had a date/time stamp.
/Hans
These opinions are my my own. My employer, Oracle Corp., may or may not
agree and assumes no responsibility for them.
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Apr 28 2016 - 15:04:02 CEST