RE: Use the existing RAC. . . or build another one?
Date: Thu, 16 Apr 2015 14:51:46 +0000
Message-ID: <1AFD62082EEAF0448EF1815139687F132BC15338_at_NC2PWEX504.us.ad.lfg.com>
With only the information you gave to go on, my first instinct would be to put them on the same cluster. However, this is hard to decide without knowing things like activity, #users, etc. If the two combined won't overwhelm your compute/memory at their peaks, I think going to one cluster will have both financial and manpower savings.
Since they are tied so closely together, it sounds like perhaps one might be useless without the other, so, if you have to apply a patch to one, you might as well take the other down and do the same. For things like PSU's or even patchsets it could cut down on downtime and work.
In a similar light, what if you have to roll back a patch? Would be easier to do it to just one instead of two. On the other hand, if you want a little separation, you could house each product database in its own ORACLE_HOME on the same cluster. This way, you would only have to patch one GRID_HOME, but, could patch the DB_HOME's separately.
Are you virtualizing these clusters? If so, I could maybe see separate clusters because of the reduced physical resource footprint and better caging of resources without licensing a whole new physical cluster.
Chris..
Chris Ruel * Oracle Database Administrator * Lincoln Financial Group cruel_at_lfg.com<mailto:cruel_at_lfg.com> * Desk:317.759.2172 * Cell 317.523.8482
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hubler, Daniel
Sent: Thursday, April 16, 2015 10: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.
Notice of Confidentiality: **This E-mail and any of its attachments may contain Lincoln National Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Lincoln National Corporation family of companies. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. Thank You.**
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Apr 16 2015 - 16:51:46 CEST