Re: RAC OCR/Voting Size
- From: Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>
- To: smishra_97@xxxxxxxxx
- Date: Thu, 4 Jun 2009 01:22:43 -0300
I don't think there is anything wrong with wasting the space... except the
actual wasting the space thing. But as for performance/best practices it's
preferrable.
Never forget that I come from a third world country, where customer pay for
each GB of storage, so they refuse to waste even a single MB. I had a hard
enough time explaining what OCR/Voting was so they'd approve the LUNs for
them...and they were 100M LUNs... XD
However, OCFS2 or any clustered filesystem is a valid option (if it works)
to store OCR/Voting.
hth
Alan Bort
Oracle Certified Professional
On Wed, Jun 3, 2009 at 7:32 PM, Sanjay Mishra <smishra_97@xxxxxxxxx> wrote:
> Thanks Matt
>
> ------------------------------
> *From:* Matthew Zito <mzito@xxxxxxxxxxx>
> *To:* Sanjay Mishra <smishra_97@xxxxxxxxx>; oraclelist@xxxxxxxxxxxxx;
> oracle-l@xxxxxxxxxxxxx
> *Sent:* Wednesday, June 3, 2009 6:25:31 PM
>
> *Subject:* RE: RAC OCR/Voting Size
>
>
> 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 <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<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<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<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:
