Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Single ASM instance for non-RAC and RAC instances in a node ?

RE: Single ASM instance for non-RAC and RAC instances in a node ?

From: <krish.hariharan_at_quasardb.com>
Date: Wed, 21 Nov 2007 20:52:18 -0700
Message-ID: <014201c82cbb$15a01ba0$6401a8c0@BHAIRAVIPC01>


Jay,  

In that case I would suggest that you set this database up as a RAC instance, to perhaps preserve environment purity, however, use the services framework instead to direct load to a specific node or set of nodes and keep the instances/services disabled where you don't want them to run. The only time I have non RAC in a RAC clusters is when I migrate a single instance to RAC (using RMAN/Dataguard) and thus a transient state. The other reason why I would create the database as a clustered database, is that some times network for database backup may not be available from all nodes (or perhaps configured to be optimal in a specific node of the cluster) and in this case you would want the database instances of the RAC available in that node from which the backup takes place.  

As to multiple databases in a RAC cluster. I have done this for a couple of reasons  

  1. Political: In general application groups have been reluctant to share servers and therefore to force them to share a database (schema stacking) would prove detrimental to our platform consolidation strategy.
  2. Too many eggs in one basket: We have had database corruption due to variety of errors and RAC will not prevent that. If multiple applications reside in a single database we would see a larger outage for the business. You could make the same argument about RAC (CRS/CSS, and ASM) and we have tried to balance that with the number of clusters we have (I have seen our RAC instances taken down because of crsd hangs).
  3. Database version upgrades can be a bit of a challenge if you put multiple schema in the same database (argument applies equally to the strategy above with a twist). More often than not the applications don't wish to have their database's version changed without some prior testing and this cannot be coordinated if you put many application "databases" as schema in a single RAC database. I consider it a less risky (and perhaps more viable) proposition to upgrade CRS and ASM to support a database upgrade in the cluster.

-Krish
 

--

http://www.freelists.org/webpage/oracle-l Received on Wed Nov 21 2007 - 21:52:18 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US