HA Oracle and ASM

Question

Hi, I wonder if anyone has experiences in running the above configuration in SUN Cluster. As far as I know, ASM is not yet supported by the SC Oracle HA Agent and for this reason ASM is just certified for RAC on SC. Anyway, there is no good reason why ASM should not be used for HA solutions as well (instead of RAW devices or a filesystem based configuration), even though the ASM instance must be started by a GDS ressource before the database comes up. Are there any plans to integrate ASM into the SC Oracle HA Agent ?
Thanks, Marc

Answer 1

Tim,
thanks for this and sorry for my late response. Anyway, I disagree with most of the issues:
1) Yes, the hostname is stored in the OCR, but without CRS, the OCR is not shared, but per default locally stored beneath $ORACLE_HOME, for instance: /orahome/oracle/product/10.2.0.2/db/cdata/localhost/local.ocr
So there is no problem with OCR as long as $ORACLE_HOME is locally stored on each cluster node. Furthermore there is a library provided by SUN for older OAS environments to keep the hostname consistent to OAS in SUN Cluster regardless to the real hostname of the cluster node (libloghost_64.so). This could additionally solve the problem in case of a shared $ORACLE_HOME, but in fact there is no need for a shared $ORACLE_HOME and local installations avoid this problem at all.
2) I fully agree, you will have a local ASM instance on each node using it's own OCR (see above).
3) I also agree, the only point to take care about is to integrate startup, shutdown and monitoring of the ASM instance(s) needded to serve the database into SC. This can be done easily by using GDS.
4) Yes the greate advantage of ASM is that DG configuration information is stored as part as header information on the disks. But there is no need zero out the configuration at all to import the DGs to another server. Just shutdown the original ASM instance first (as without RAC the ASM instances shoud be prevented to import the DGs concurrently), switch over the DCS and start the other ASM instance on the failover node. By starting the instance ASM imports all DGs stored on the disks which match the asm_diskstring, in my case asm_diskstring='/dev/did/rdsk/*', because there is just one database.
Moreover this way of failing over ASM is supported by Oracle (for instance for an OAS infrastructure database, see http://download-east.oracle.com/docs/cd/B25006_01/install.1012/install/ha_cfc.htm#BABEADDA). As mentioned in my previous posting I tested this constellation running a local ASM instance (+ASM) on each cluster node and one failover database:
Resource Name  Node Name                State          Status Message
  Resource: HW1P-lh-res    fix                      Online         Online - LogicalHostname online.
  Resource: HW1P-lh-res    foxi                     Offline        Offline - LogicalHostname offline.
  Resource: HW1P-dg-res    fix                      Online         Online
  Resource: HW1P-dg-res    foxi                     Offline        Offline
  Resource: HW1P-asm-res   fix                      Online         Online - Service is online.
  Resource: HW1P-asm-res   foxi                     Offline        Offline
  Resource: HW1P-db-res    fix                      Online         Online
  Resource: HW1P-db-res    foxi                     Offline        OfflineI have to admit, that things will get more difficult in case of several failover databases in the same cluster. But there is generally no problem to have several ASM instance on each node, each of them serving another database. So after all I can't see any technical reason for not supporting ASM for failover databases in SUN Cluster. In fact this could be also a solution to get rid of problems in environments using stoarge-based data replication. As DG information is stored on the disks and each disk matching the asm_diskstring will be scanned, ASM-DGs can be imported, even if the DIDs are differrent due to a storage failover. Thus there is no need to combine/fake DIDs like in SVM to use storage-based replication.