Simon,

Several databases can share a single ASM instance. So, although one can create multiple ASM instances on a single system, normal configurations should have one and only one ASM instance per system.

For clustered systems, create one ASM instance per node (called +ASM1, +ASM2, etc).

Thanks,

Eddy

In order to use the ASM in a shared mode for the use of RAC database, an ASM instance needs to be created for each node of the RAC database involving the same disk devices as input. Each ASM instance has either an SPFILE or PFILE type parameter file. To use ASM in the RAC environment we recommend the svrctl commands as opposed to the Oracle GUI.

When using ASM with RAC, it's critical to "load balance" the ASM diskgroups by functional area. One of the largest RAC performance problems relate to cross-node sharing of common data, and by segregating ASM diskgroups by functional area you can greatly reduce cache fusion overhead. For example, you want to create ASM groups for finance data, another for inventory data, and then map the users from those departments to those ASM disk groups via a dedicated node.

http://www.dba-oracle.com/t_using%20_adm_rac_clusters.htm

hi JingYi,

oracle recommends only 2 disk groups in a single DB system, one for data, and another for FRA(recovery purpose); because during ASM configuration, RAID 0 is setup either in storage or ASM level, hence maximum I/O is balanced across all available ASM disk group members. by segregating data based on apps funcatoin, it's pretty manual and too much dependant on apps.

for RAC, i do not see it's a exceptional case. I am not able to view the doc you posted. can you share the doc?

Alan Yao

Alan, here is the document from http://www.dba-oracle.com/t_using%20_adm_rac_clusters.htm. FYR

Using ASM with RAC

The Database Configuration Assistant (DBCA) is used in Oracle Database 10g to configure the Automated Storage Management (ASM) features for conventional and Real Application Clusters (RAC) environments. ASM is used to automate and simplify the optimal layout of datafiles, control files, and log files.

Oracle created Automatic Storage Management (ASM) as an alternative to raw devices and 3rd party clusterware (Veritas Cluster Filesystem) for Oracle Real Application Cluster (RAC) databases. Managing raw devices with the native "pp" commands are cumbersome, but you need to understand that while ASM has become the de-facto standard for Oracle, the use of ASM in RAC is somewhat different.

For complete details on the nuances of using ASM with RAC, I recommend the book Oracle Grid & Real Application Clusters.

In order to use the ASM in a shared mode for the use of RAC database, an ASM instance needs to be created for each node of the RAC database involving the same disk devices as input. Each ASM instance has either an SPFILE or PFILE type parameter file. To use ASM in the RAC environment we recommend the svrctl commands as opposed to the Oracle GUI.

ASM provides a vertical integration of the file system and volume manager for Oracle database files. ASM has the capability to spreads database files across all available storage for optimal performance and resource utilization. It enables simple and non-intrusive resource allocation and provides automatic rebalancing

Using ASM for building shared files would get almost the same performance as that of raw partitions. The ASM controlled disk devices will be part of ASM instance which can be shared by the RAC database instance.

When using ASM with RAC, it's critical to "load balance" the ASM diskgroups by functional area. One of the largest RAC performance problems relate to cross-node sharing of common data, and my segregating ASM diskgroups by functional area you can greatly reduce cache fusion overhead. For example, you want to create ASM groups for finance data, another for inventory data, and then map the users from those departments to those ASM disk groups via a dedicated node.

I got some interesting blogs on we create multiple ASM instances. Maybe the link is useful for reference.

As author summarized :

• It is possible to run multiple ASMs on a node 
• One RDBMS can onlybe served by one ASM
   
• all the GUIs are not aware of multiple ASMs 
• it's not supported in RAC

Hope it useful. And need your confirm.

Generally speaking one should have only one disk group for all database files - and, optionally a second for recovery files, FRA.

Data with different storage characteristics should be stored in different disk groups. Each disk group can have different redundancy (mirroring) settings (high, normal and external), different fail-groups, etc. However, it is generally not necessary to create many disk groups with the same storage characteristics (i.e. +DATA1, +DATA2, etc. all on the same type of disks).

Eddy

The Symmetrix guidelines for the number of ASM disk groups are generally covered in this white paper (pg. 25):

http://www.emc.com/collateral/hardware/white-papers/h8131-storage-tiering-oracle-vmax-wp.pdf

Note that Oracle joint-logo it so it isn't in conflict with Oracle recommendation of 2 disk groups, just an adjustment based on common sense.

So like it was said, Oracle planned for ASM instance to be one per host (although you can cheat and have more, it doesn't make a whole lot of sense and it takes a lot of work to do). Isolation can be achieved by using different ASM disk groups. High availability is achieved by using RAC and replication technologies (such as TimeFinder, SRDF, RecoverPoint, Data Guard, etc.).

Yaron

Thanks for the information, Yaron!  From this EMC proven solution Oracle ASM and Symmetrix FAST VP can complement each other very well.  With a broad range of data protection mechacisms and tighter integration between Symmetrix and Oracle now available  even for thin devices, adoption of FAST VP for Oracle environments is very desirable.