Re: RAC OCR/Voting Size
Date: Thu, 4 Jun 2009 01:22:43 -0300
Message-ID: <172762180906032122w502c78d0yc0923b61ada8ecbd_at_mail.gmail.com>
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_at_yahoo.com> wrote:
> Thanks Matt
>
> ------------------------------
> *From:* Matthew Zito <mzito_at_gridapp.com>
> *To:* Sanjay Mishra <smishra_97_at_yahoo.com>; oraclelist_at_sbcglobal.net;
> oracle-l_at_freelists.org
> *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_at_gridapp.com
> http://www.gridapp.com
>
>
>
> -----Original Message-----
> From: Sanjay Mishra [mailto:smishra_97_at_yahoo.com <smishra_97_at_yahoo.com>]
> Sent: Wed 6/3/2009 6:24 PM
> To: Matthew Zito; oraclelist_at_sbcglobal.net; oracle-l_at_freelists.org
> 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_at_gridapp.com>
> To: oraclelist_at_sbcglobal.net; oracle-l_at_freelists.org
> 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org<oracle-l-bounce_at_freelists.org>]
> On Behalf Of Randy Johnson
> Sent: Wednesday, June 03, 2009 3:37 PM
> To: oracle-l_at_freelists.org
> 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org<oracle-l-bounce_at_freelists.org>]
> On Behalf Of Mark W. Farnham
> Sent: Wednesday, June 03, 2009 3:46 AM
> To: cicciuxdba_at_gmail.com; smishra_97_at_yahoo.com
> Cc: oracle-l_at_freelists.org
> 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org<oracle-l-bounce_at_freelists.org>]
> On Behalf Of Guillermo Alan Bort
> Sent: Tuesday, June 02, 2009 10:41 PM
> To: smishra_97_at_yahoo.com
> Cc: oracle-l_at_freelists.org
> 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/>
>
>
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jun 03 2009 - 23:22:43 CDT