RE: FW: Use the existing RAC. . . or build another one?
- From: "Powell, Mark" <mark.powell2@xxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 17 Apr 2015 18:19:58 +0000
I also see no real issue with running multiple RAC instances on the same set of
servers. Separate clusters vs shared is a local environment consideration.
Something you might consider while making the choice is customer ownership.
Some customers do not want to let you take a maintenance window to apply
patches or upgrades even when they are not working while others will tell you
to go ahead and take 15 minutes to bounce the system over the scheduled
assembly line lunch break.
And another consideration is how the local budget for IT hardware and software
is handled. If individual departments pay the bill you may find it is easier
to have separate resources than to use shared ones.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Jeremy Schneider
Sent: Thursday, April 16, 2015 1:12 PM
To: daniel.hubler@xxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: FW: Use the existing RAC. . . or build another one?
From: Hubler, Daniel
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.
On Thu, Apr 16, 2015 at 10:56 AM, Hubler, Daniel <daniel.hubler@xxxxxxxxxx>
wrote:
So my question is more of a "best practices" idea.
From a "best practices" perspective, I think multiple clusters and multiple
database on a single cluster are both rather equal. It's not uncommon to have
plenty of both. I've got lots of clusters, with lots of databases on each
cluster and lots of apps in each database. In my opinion there's not a
"generally" better choice between multiple clusters vs multiple db's on a
cluster - it is entirely situational.
Several good things to consider have already been mentioned:
- using OS virtualization
- multiple oracle homes
- vendor certifications (even w same vendor, products could get different
certification levels over time)
- patching, other maintenance (pros/cons both ways with this)
- licensing/cost (even if it's supposedly a "non-issue" you should still
consider it. even with site licensing, current usage can play into future
negotiations.)
- current utilization
one additional idea i would submit for consideration is how you partition the
workload. i think an excellent configuration is to have a single cluster but
partition the workload -- have one app run on the first few nodes and the
second app run on the remaining nodes.
(services anyone? <g>) in fact, if you can manage to have a single node handle
the workload for each app, then you can avoid quite a few interconnect and
cluster headaches.
i completely agree with Chris Taylor and Chris Ruel, in that my instinct would
be to have a single cluster. also, having spent a lot of time both supporting
clusters and helping other DBAs learn about clusters, i have a very strong
instinct to keep things absolutely as simple as possible.
--
http://about.me/jeremy_schneider
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
