RE: Questions consolidating databases onto RAC Cluster

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Thu, 28 Apr 2016 18:24:04 -0400
Message-ID: <01cf01d1a19c$acda68e0$068f3aa0$_at_rsiz.com>

I tend to agree with the sentiments in the thread. I would, however, like to point out that a decent case can probably be made for evading the RAC tax altogether when reasons exist for databases to remain separate and the requirements of any single database’s peak resource demand can be serviced by a single node.  

There are pros and cons to each approach, for example, when one database is nearly idle but you need to keep it open you’ve got its full memory footprint pinned and all its process information still occupies footprint on the server. (That is the sort of resource sharing vs non-sharing argument that leads to net value for the container-pluggable database architect in some cases.)  

On the pro side, each database has its own distinct recovery thread (and log writer), it is easier to manage kept procedures, kept tables, and column stores, and concurrent latch contention is reduced to that driven by that the schemas and programs for that particular logical database as an isolated physical database. Oh, and don’t get me started about operationally distinct patch and upgrade windows!  

My personal opinions on where the sweet balance plateau is have differed with general advice from Oracle since at least 1990 since I could run 10 databases, five each on a single Sequent as distinct one instance databases and get the full production load of Burlington Coat Factory Warehouse to process with plenty of slippage time while Oracle’s attempts to match that performance with consolidation did not pass the laugh test. In fairness, they gave up pretty quickly when they realized game set and match was running ten independent recovery streams. With the failure rate of non-duplexed drives back then it also made no sense to combine multiple (then massive) 7 gigabyte databases together. My idea of non-stop processing back then was “If I can keep nine of ten departments running processing AP while I’m recovering the one that had a busted disk drive, that is better than having zero service while I recover.” Of course that was before the VLDB request to allow a database to open after all the essential tablespaces were recovered and back then recovery had to complete before you could proceed on any tablespace.  

But my bias was driven from serving a particular real case. If you had an application too big for a single server and you HAD TO go “RAC” (which was probably Oracle Parallel Server with distributed transactions pumped through a per hardware vendor “distributed lock manager” DLM) then Tommy’s advice would be dead bang on: Trying to push two (or more!) distinct sets of lock manager traffic through the load sensitive DLM would have been a recipe for disaster. I’m glad his advice was referenced as outdated rather than wrong.  

Now, though, I’d go with what Mark Bobak and others have said as the starting point for a reasonable specific deployment topology. Just remember that you do pick up the burden of making sure multiple competing RAC databases don’t overload the network amongst the hosts; there is a real danger of one consistent heavy transmission between RAC instances of one database to generate timeouts for the communication between RAC instances of another database and hilarity might well result. But that is just one more thing to manage, not a death sentence to the idea.  

Me? I’d try to convince folks to go non-RAC with the whole shooting match and allocate the databases that don’t need to be together logically to the various hosts. But I’d only do that based on load profiles and analysis, not my bias against RAC and consolidation. All of these things are slippery slopes and therefor require thinking.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Powell, Mark Sent: Thursday, April 28, 2016 3:12 PM
To: ORACLE-L
Subject: RE: Questions consolidating databases onto RAC Cluster  

I agree with Mark Bobak. We have ran as many as 13 side by side RAC databases on a server without issue. As long as your server has capacity you can do it. Where some people think this is a problem is if your server, especially the disk, is showing heavy load in figuring out where the load is coming from. The Top/Topmonitor and other UNIX/OS utilities can generally pin-point where the load is coming from and then you tune the instance as normal. Disk tools can identify where the IO is coming from if not obvious from the OS utilities. Generally speaking finding conflicting demand from the database instances is not an issue.    

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark J. Bobak Sent: Wednesday, April 27, 2016 5:09 PM
To: Chris Taylor <christopherdtaylor1994_at_gmail.com> Cc: ORACLE-L <oracle-l_at_freelists.org> Subject: Re: Questions consolidating databases onto RAC Cluster  

I'm not currently running any RAC at my current employer.  

However, I've run RAC clusters with multiple databases on them in the past with no issues.  

I'd argue that the considerations and trade offs are similar to single instance, in terms of memory and CPU resources and availability. If you have multiple schemas that support multiple applications, and that DB goes down, all your applications are down. Question is, do you have enough spare memory and CPU to run multiple instances on a node?  

But, there's nothing inherently bad about multiple DBs on a single RAC cluster. At least, no more so than you'd expect. When you run into performance problems and/or resource issues, you'll have multiple places to look.  

Of course, regardless of how many DBs in your cluster, you *must* run only one GI Home, and its version must be greater than or equal to the highest version DB.  

Hope that helps,  

-Mark
 

On Wed, Apr 27, 2016 at 4:13 PM, Chris Taylor <christopherdtaylor1994_at_gmail.com> wrote:

After doing some research, it appears that common wisdom is to NEVER have 2 different RAC databases sharing the same cluster.  

For example:
2 Node RAC with more than one RAC DB  

Is this still true?
Reference: <https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1855800700346081917> https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1855800700346081917  

If you have a RAC DB on 2 nodes, but the nodes are only 10% utilized, is the only best option really to migrate the schemas into the existing RAC DB instead of adding separate RAC DBs to the existing cluster?  

Is there some other option here that I'm missing to take advantage of the spare resources on the RAC cluster hosts? (Other than 12c and multi-tenant)  

Chris  

--

http://www.freelists.org/webpage/oracle-l Received on Fri Apr 29 2016 - 00:24:04 CEST