Friday, March 6, 2015

OCSSD starts if voting disk & OCR resides in ASM Diskgroups?

OCSSD starts if voting disk &
OCR resides in ASM Diskgroups?

Voting & OCR Disk resides in ASM Diskgroups, but as per startup sequence OCSSD starts first before than ASM, how is it possible?

How does OCSSD starts if voting disk & OCR resides in ASM Diskgroups?


You might wonder how CSSD, which is required to start the clustered ASM instance, can be started if voting disks are stored in ASM? 

This sounds like a chicken-and-egg problem: without access to the voting disks there is no CSS, hence the node cannot join the cluster. But without being part of the cluster, CSSD cannot start the ASM instance. 

To solve this problem the ASM disk headers have new metadata in 11gR2 (11.2.x.x) you can use kfed to read the header of an ASM disk containing a voting disk. 

The kfdhdb.vfstart and kfdhdb.vfend fields tell CSS where to find the voting file. This does not require the ASM instance to be up. Once the voting disks are located, CSS can access them and joins the cluster.


Use kfed to read ASM disk header block.

# displays online help for the utility

$ kfed -help

# reads the disk header to stdout

$ kfed op=read dev=/dev/mapper/postrf741_11p1

# reads the specified AU and block into file /tmp/a

$ kfed op=read dev=/dev/mapper/postrf741_11p1 aunum=3 blknum=3 text=/tmp/a

# writes from /tmp/a into the specified AU and block
#block checksum is computed and written together with data

$ kfed op=write dev=/dev/mapper/postrf741_11p1 aunum=3 blknum=3 text=/tmp/a

No comments:

Post a Comment