RE: RAC OCR/Voting Size
- From: "Matthew Zito" <mzito@xxxxxxxxxxx>
- To: "Sanjay Mishra" <smishra_97@xxxxxxxxx>, <oraclelist@xxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 3 Jun 2009 18:25:31 -0400
Yes, I would take three luns, make small partitions on two of them for OCR, and
on all three for voting, and then use the rest of the space on the disks for
ASM. Now, no disk space wasted.
As far as why you can't access the devices, have your SAN admin open a case
with EMC - there may be FA bits that need to be flipped for RAC support.
Matt
--
Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
mzito@xxxxxxxxxxx
http://www.gridapp.com
-----Original Message-----
From: Sanjay Mishra [mailto:smishra_97@xxxxxxxxx]
Sent: Wed 6/3/2009 6:24 PM
To: Matthew Zito; oraclelist@xxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: RAC OCR/Voting Size
Matt
These are completely new EMC SAN but SAN admin says that all space is allocated
and cannot be changed. So if I have to redundancy at Cluster level is it 5 Lun
and so wastes of 100's of gigabytes waste.
ANother question I am working on this AIX server and getting the issue in
sharing this LUN among three Nodes. I checked that LUN assigned are having PVID
none and no_reserve=no and permission are correct. SAN people also says that
permission are correct as per other RAC environment. Cluster start is giving
error
OCR initialization failed accessing OCR device: PROC-26: Error while accessing
the physical storage Operating System error [Device busy] [16]
So only One node is coming up and if i stopped that node, then Cluster is
coming on Second Node.
Is there any document that can tell as what setting are required to be checked
on EMC side for OCR Luns
Sanjay
________________________________
From: Matthew Zito <mzito@xxxxxxxxxxx>
To: oraclelist@xxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Sent: Wednesday, June 3, 2009 5:41:32 PM
Subject: RE: RAC OCR/Voting Size
So, there are storage arrays where once a fixed volume size is defined, it is
extremely difficult/expensive/risky to modify it, or provide alternately sized
devices. Older IBM and EMC arrays had this limitation - hearkens back to the
mainframe days, actually.
If this is a linux system, you could put an OCFS2 filesystem on both of the
devices, and then keep extra control files, etc. there.
Matt
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Randy Johnson
Sent: Wednesday, June 03, 2009 3:37 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: RAC OCR/Voting Size
Or you could just use 1 partition from each of several LUNs for your OCR &
Voting. Use the rest of the space on each LUN for something else like ASM
volumes.
By the way I find it hard to believe your storage admin cannot give you less
than 75G LUN's. It is probably more "rather not" than "cannot".
-Randy
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Mark W. Farnham
Sent: Wednesday, June 03, 2009 3:46 AM
To: cicciuxdba@xxxxxxxxx; smishra_97@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: RAC OCR/Voting Size
While that indeed should work, it has all the same use profile problems of
putting all your control file copies on the same LUN.
My advice would be to "waste" the excess space on each LUN. Further, the LUNs
thus "wasted" should ideally be composed of media using disjoint components all
the way down to the physical media.
This may be a case where SSD could usefully be worked into the storage matrix,
since the waste savings might well pay for the required amount of SSD.
Regards,
mwf
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Guillermo Alan Bort
Sent: Tuesday, June 02, 2009 10:41 PM
To: smishra_97@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: RAC OCR/Voting Size
You can have a single LUN and have separate partitions within that LUN for
OCR/Voting, and leave the rest as ASM disks.
hth
Alan Bort
Oracle Certified Professional
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4128 (20090603) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4128 (20090603) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com <http://www.eset.com/>
Other related posts:
