Re: Questions consolidating databases onto RAC Cluster
- From: Hans Forbrich <fuzzy.graybeard@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 28 Apr 2016 07:04:02 -0600
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.
Other related posts: