asm1

• Is it recommended that we put the OCR/Voting Disks in Oracle ASM and, if so, is it preferable to create a separate disk group for them?

  With Oracle Grid Infrastructure 11g Release 2, it is recommended to put the OCR and Voting Disks in Oracle ASM, using the same disk group you use for your database data. For the OCR it is also recommended to put another OCR location into a different disk group (typically, the Fast Recovery Area disk group, a.k.a. FRA) to provide additional protection against logical corruption, if available.
  
  Using the same disk groups for the Oracle Clusterware files (OCR and Voting Disks) simplifies (you do not have to create special devices to store those files) and centralizes the storage management (all Oracle related files are stored and managed in Oracle ASM), using the same characteristics for the data stored.
  
  If the Voting Disks are stored in an Oracle ASM disk group, the number of Voting Disks that will be created in this disk group and for the cluster is determined by the redundancy level of the respective disk group. For more information, see Voting Files stored in ASM - How many disks per disk group do I need? The Voting Disks for a particular cluster can only reside in one disk group.
  
  In case "external redundancy" has been chosen for the disk group that holds the database data, it is assumed that an external mechanism (e.g. RAID) is used to protect the database data against disk failures. The same mechanism can therefore be used to protect the Oracle Clusterware files, including the Voting Disk (only one Voting Disk is created in an "external redundancy disk group").
  
  Under certain circumstances, one may want to create a dedicated disk group for the Oracle Clusterware files (OCR and Voting Disks), separated from the existing database data containing disk groups. While having a dedicated disk group is not required, it can be configured and might be useful under certain circumstances. Potential scenarios include, but are not limited to: 
  
  

• A 1:1 relationship between disk groups and databases is preferred and disk groups are generally not shared amongst databases.
• The backup and recovery for individual databases (more than one in the cluster) is based on a snapshot restore mechanism (BCVs). This approach is most likely used in conjunction with a 1:1 disk group to database relationship as mentioned before.
• Certain and frequent system specific maintenance tasks uncommonly require to unmount specific, database data containing disk groups. This scenario can most likely be avoided using a different approach for those maintenance tasks.
• When using a disk group that contains a quorum failgroup in addition to regular failgroups (typically used in extended distance Oracle RAC clusters) and when access to the disk(s) in the quorum failgroup may be subject to failure together with any other failgroup in the same disk group or access to the disk(s) in the quorum failgroup is otherwise considered unreliable.
• A higher protection level than the one provided for the "external redundancy disk groups" and therefore for the database data is for some reason required for the Oracle Clusterware files.

Voting Files stored in ASM - How many disks per disk group do I need?

If Voting Files are stored in ASM, the ASM disk group that hosts the Voting Files will place the appropriate number of Voting Files in accordance to the redundancy level. Once Voting Files are managed in ASM, a manual addition, deletion, or replacement of Voting Files will fail, since users are not allowed to manually manage Voting Files in ASM. 

If the redundancy level of the disk group is set to "external", 1 Voting File is used. 
If the redundancy level of the disk group is set to "normal", 3 Voting Files are used. 
If the redundancy level of the disk group is set to "high", 5 Voting Files are used. 

Note that Oracle Clusterware will store the disk within a disk group that holds the Voting Files. Oracle Clusterware does not rely on ASM to access the Voting Files. 

In addition, note that there can be only one Voting File per failure group. In the above list of rules, it is assumed that each disk that is supposed to hold a Voting File resides in its own, dedicated failure group. 

In other words, a disk group that is supposed to hold the above mentioned number of Voting Files needs to have the respective number of failure groups with at least one disk. (1 / 3 / 5 failure groups with at least one disk)

Consequently, a normal redundancy ASM disk group, which is supposed to hold Voting Files, requires 3 disks in separate failure groups, while a normal redundancy ASM disk group that is not used to store Voting Files requires only 2 disks in separate failure groups.