Re: FW: Use the existing RAC. . . or build another one?

  • From: MARK BRINSMEAD <mark.brinsmead@xxxxxxxxx>
  • To: daniel.hubler@xxxxxxxxxx
  • Date: Thu, 16 Apr 2015 11:16:07 -0400

If the choice is to expand a two-node-cluster to a four-node-cluster, or to
deploy two two-node-clusters, then license and hardware costs are moot.
They ought to be about the same either way.

There will be a little more effort involved in maintaining two clusters
rather than one. But this might be offset by the work you might otherwise
find yourself doing with Resource Manager to make sure that the two
databases both play well with others on shared hardware.

There should be little stopping you from setting it all up as one cluster
now, and splitting it into two later, should you eventually need to do
that. (Maybe you might want to plan your storage to facilitate that, just
in case.)

I think the only determining issue would be how likely the COST vendors are
to insist on difference versions of clusterware. I would go with
independent ORACLE_HOMEs in any event -- its almost assured that one vendor
will eventually force you to apply an update or patch that the other vendor
will refuse to support.

On Thu, Apr 16, 2015 at 10:56 AM, Hubler, Daniel <daniel.hubler@xxxxxxxxxx>
wrote:

Something I should have made clear (and thanks to Chris Taylor and Chris
Ruel):





Funds are available to either grow the existing environment, or acquire
the resources needed to build a new one.





So my question is more of a “best practices” idea.





Thanks again to all.











Daniel Hubler

Aurora Healthcare

IT Infrastructure

daniel.hubler@xxxxxxxxxx



*From:* Hubler, Daniel
*Sent:* Thursday, April 16, 2015 9:27 AM
*To:* oracle-l@xxxxxxxxxxxxx
*Subject:* Use the existing RAC. . . or build another one?



We have to decide if we are going to put a new database instance in our
existing 2-node RAC,

or build a second cluster for the new database.



We are talking 2 separate off-the-shelf products from a single vendor; the
vendor will not support putting the 2 schemas into a single database.



The 2 products are tied very closely together; but do operate
independently when/if necessary.



We are debating amongst ourselves the pros/cons of each strategy.



Any comments/suggestions/war-stories would be appreciated.



Thanks.



Other related posts: