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

From: MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
Date: Thu, 16 Apr 2015 11:16:07 -0400
Message-ID: <CAAaXtLAWwX4CBWrZfbNZ-PETaLXqjaxk+9KUgY5AfxAafyGWhg_at_mail.gmail.com>

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_at_aurora.org> 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_at_aurora.org
>
>
>
> *From:* Hubler, Daniel
> *Sent:* Thursday, April 16, 2015 9:27 AM
> *To:* oracle-l_at_freelists.org
> *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.
>
>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Apr 16 2015 - 17:16:07 CEST