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

• Cost. Assuming you are licensed per processor (actually, this assumption may not matter), adding a second cluster will double your Oracle license costs. If we're talking EE, this is far from an insignificant consideration. (Even if you are licensed by named-users, a second cluster will double your *minimum* license count, so it will only be cost-neutral if you are already well above the minimum.)
• Updates. Its unlikely that both vendors will (always) support the same major versions, patchsets, or one-off patches. When they permit upgrades -- or mandate them -- they are unlikely to do so in lockstep. This means being prepared to manage two sets of ORACLE_HOMEs, whether you have a shared cluster or not.
  • The real questions here are:
    • Will *both* vendors support a difference in versions between database and clusterware?
    • Will *both* vendors in fact permit the same version of clusterware? Always?

Running two COTS applications on the same cluster may set you on the road to a compatibility-matrix-nightmare.

Setting up two independent clusters is the "safe" and "conservative" thing to do -- it eliminates a number of risks, and also helps to isolate failures when they do happen. (Even RAC clusters sometimes fail, but you have to be pretty clever about it to make *two* clusters fail at the same time.) Sadly, this safety comes at a potential (very) high cost.

This may be a decision for your risk management people. Is the cost of the insurance policy you propose to buy (two separate clusters, to avoid support issues and isolate failures) greater or less than the cost of the problems you seek to avoid?

On Thu, Apr 16, 2015 at 10:26 AM, Hubler, Daniel <daniel.hubler_at_aurora.org> wrote:

> 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