RE: Single ASM instance for non-RAC and RAC instances in a node ?
- From: <krish.hariharan@xxxxxxxxxxxx>
- To: <jayaraj.rengarajan@xxxxxxxxx>
- Date: Wed, 21 Nov 2007 20:52:18 -0700
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
Other related posts:
