IMPORTANT POINTS
=================
I/O LOAD BALANCING
===================
> in production never present multiple luns to ASM carved from the same disks.
> ASM rebalancing operations are controlled by the size of the disks in a disk group
OCR
====
> NOT recommended to put database files and clusterware files ( OCR, SMSPFILE and VOTING) together. This can disrupt the management of the environment and cause dowtime. (e.g you never can stop this diskgroup) . Also You can move only vote and ocr without downtime, but to move ASMSPIFILE you need downtime.This is required to ASM use new SPFILE and release the old Diskgroup. *ORA-15027: active use of diskgroup precludes its dismount (With no database clients connected) [ID 1082876.1*]
> Oracle Clusterware rely on ASM to access the OCR. The OCR is stored similar to how Oracle Database files are stored.The extents are spread across all the disks in the diskgroup and the redundancy (which is at the extent level) is based on the redundancy of the disk group. For this reason you can only have one OCR (or SPFILE) in a diskgroup. So, if your Diskgroup where OCR is stored become unavaliable you will lose your OCR.Then we need put OCR mirror in another disk group to support failure of disk group.
> what happens if you have the OCR mirrored and one of the copies gets corrupt >>
# If the corruption happens while the Oracle Clusterware stack is up and running, then the corruption will be tolerated and the Oracle Clusterware will continue to funtion without interruptions. DBA is advised to repair this hardware/software problem that prevent OCR from accessing the device as soon as possible; alternatively, DBA can replace the failed device with another healthy device using the ocrconfig utility with -replace flag.
# If however the corruption happens while the Oracle Clusterware stack is down, then it will not be possible to start it up until the failed device becomes online again or some administrative action using ocrconfig utility with -overwrite flag is taken.
> The COMPATIBLE.ASM disk group compatibility attribute must be set to 11.2 or greater to store OCR or voting disk data in a disk group.
> Best Practice for ASM is to have 2 diskgroups to store OCR.
So below can be considered to create two small DISKGROUP:
+DG_VOTE - Storing Voting files and OCR mirror ( Create 3 Luns of 500Mb each. If possible put each Lun in different controller, array or storage. )
+DG_OCR - Storing OCR and ASM Spfile. ( If you are using mirror of storage or you are using only one storage, it’s recommended you create 1(one) Lun using external redundancy. )
Putting voting files in a diskgroup separately, because it has different characteristics of settings and access from other files of ASM.
from > https://forums.oracle.com/forums/thread.jspa?messageID=10028550&tstart=0#10028550
>
VOTING FILE
===========
> Voting files can be stored in only one diskgroup. You cannot place Voting files in differents Diskgroup.
> Voting disks are placed directly on ASMDISK. Oracle Clusterware will store the votedisk on the disk within a disk group that holds the Voting Files. Oracle Clusterware does not rely on ASM to access the Voting Files.
> The COMPATIBLE.ASM disk group compatibility attribute must be set to 11.2 or greater to store OCR or voting disk data in a disk group.
> If you are using ASM the maximum number of voting files is 5.
> You should have at least three voting disks, unless you have a storage device, such as a disk array, that provides external redundancy.
> A voting disk by default needs to have 3 copies. Not 2. If you are using raw devices (storage LUNs directly), then you need 3 raw devices for voting files. This can also be done (assuming external redundancy already exist in the storage layer) by partitioning a large enough LUN into 3 partitions and using these as voting file locations.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>