Voting disk changes in Oracle 11gR2

There are few noticeable changes made in 11gR2 specific to voting disks.

As we are aware that Voting disk and OCR can now be stored in ASM. But we also know in previous versions, CSS need voting disk to start.

So how grid starts, when voting disk is in ASM diskgroup?

I’ve created ASM diskgroup DATA and my voting and OCR resides in it.

SQL> select name, type, total_mb, usable_file_mb 
from v$asm_diskgroup;
------ ------   ---------- --------------
DATA   EXTERN   3072       2672

SQL> set line 200
SQL> column path format a30
SQL> select name, path, header_status from v$asm_disk;
------     ------- ------------
DATA_0002 /dev/sdg   MEMBER
DATA_0000 /dev/sdi   MEMBER
DATA_0001 /dev/sdh   MEMBER

crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
 1. ONLINE 4f2e374b254e4f57bf85ac5db31a91fb (/dev/sdi) [DATA]
Located 1 voting disk(s).

Few more things –

1. Voting disks are stored on individual disks Vs OCR which are stored as files in the ASM diskgroup. So voting disks will not span multiple disks i.e. they are confined in single disk.

2. At the start of ohasd, all disks as part asm_diskstring are scanned. ohasd know about asm_diskstring from GPnP profile. This functionality allows CSS start before ASM.

3. How ohasd will know which disk contains voting disk?

Following is the ASM disk header metadata (dumped using kfed). ohasd use the markers between vfstart & vfend. If the markers between vfstart & vfend are 0 then disk does *NOT* contain voting disk

grid@db1:~> kfed read ‘/dev/sdi’ | grep vf
kfdhdb.vfstart: 128 ; 0x0ec: 0x00000080
kfdhdb.vfend: 160 ; 0x0f0: 0x000000a0

grid@db1:~> kfed read ‘/dev/sdg’ | grep vf
kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000
kfdhdb.vfend: 0 ; 0x0f0: 0x00000000

grid@db1:~> kfed read ‘/dev/sdh’ | grep vf
kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000
kfdhdb.vfend: 0 ; 0x0f0: 0x00000000

So from above output, disk ‘/dev/sdi’ contains voting disk.

4. Number of voting disks, is decided based on the diskgroup redundancy.

5. If we want to store a voting disk in a new diskgroup (apart from one, which already holds a voting disk) we need to create a QUORAM failure group.

From Oracle docs – A quorum failure group is a special type of failure group and disks in these failure groups do not contain user data and are not considered when determining redundancy requirements.

6. Manual backup of the voting disk is not required anymore. Required data is backed up along with OCR backup.


This entry was posted in Oracle 11.2.0.x, Oracle 11g Enhancements, Oracle Cluster Ready Services, Oracle Grid, Oracle Real Application Cluster and tagged . Bookmark the permalink.

One Response to Voting disk changes in Oracle 11gR2

  1. Clesisniara says:

    have read all your articles and they are all great. congratulations for hard work on this website.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s