I've been using ASMLIB for going on 2 yrs now in production on 22 servers without any issues. We use EMC Powerpath which ensures the names are correct on reboots. On Thu, Oct 28, 2010 at 10:24 AM, Bobak, Mark <Mark.Bobak@xxxxxxxxxxxx>wrote: > Jeremy makes a good point. As long as permissions are good, and the device > naming matches what's specified in asm_diskstring, ASM will happily discover > all the required disks and figure out how to use them. > > -Mark > > -----Original Message----- > From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] > On Behalf Of Jeremy Schneider > Sent: Thursday, October 28, 2010 10:55 AM > To: Freek.DHooge@xxxxxxxxx > Cc: Paul.McManus@xxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx > Subject: Re: High Availability Options > > Also worth noting that ASM actually doesn't require or care about > persistent device naming. The only thing that matters is getting > permissions applied correctly, so that ASM (a non-root, user process) > can access its disks. If you hard-code a "chmod" statement in your > rc.local, that's when you get messed up after device re-numbering. > But as long as permissions are correct, it doesn't actually matter to > ASM if the device name changes. > > On 10/28/10, D'Hooge Freek <Freek.DHooge@xxxxxxxxx> wrote: > > Paul, > > > > If you use linux multipathing (which is often the case), this will also > > ensure persistent device naming (certainly when you provide an alias). > > > > I like to use udev to then create the devices for asm (based upon the > alias > > name given in multipath) in a separate directory to avoid picking a > device > > that was not ment to be used for asm. > > (and to set the ownership / privileges correctly). > > > > Regards, > > > > Freek D'Hooge > > Uptime > > Oracle Database Administrator > > email: freek.dhooge@xxxxxxxxx > > tel +32(0)3 451 23 82 > > http://www.uptime.be > > disclaimer: www.uptime.be/disclaimer > > ________________________________________ > > From: oracle-l-bounce@xxxxxxxxxxxxx [mailto: > oracle-l-bounce@xxxxxxxxxxxxx] > > On Behalf Of Paul McManus > > Sent: donderdag 28 oktober 2010 16:01 > > To: oracle-l@xxxxxxxxxxxxx > > Subject: Re: High Availability Options > > > > > >> +1 IMHO: both udev or ASM Lib just useless. Why we should introduse > >> any additional layers when we can avoid those. > >> Keep it simple. Use devices directly (ASM will read headers for you, > >> just set the discovery string right) + rc.local will fix privileges > >> esely. > >> > >> Just my .2$, > >> Yurt > > I thought UDEV and/or ASMLIB were recommended to ensure persistent device > > naming. > > > > I have certainly seen RAC environments fall over when new LUNS were > > presented that caused the device names to switch and so messed up a > > rawdevices configuration which meant voting disks and OCR files were not > > where they were supposed to be. > > PMcM > > > > _DISCLAIMER: > > > > This message is intended only for the use of the person(s) ("the intended > > recipient(s)") to whom it is addressed. > > > > It may contain information which is privileged, proprietary and/or > > confidential within the meaning of applicable law. > > > > If you are not the intended recipient, be advised that you have received > > this email in error and that any use, dissemination, forwarding, printing > or > > copying of this message (including any attachments) is strictly > prohibited. > > > > If you have received this message in error, please contact the sender of > > this message as soon as possible. > > > > The views or opinions expressed in this message are those of the author > and > > may not necessarily be the views held by Maxima Holdings plc. > > Maxima Holdings plc. Cotswold Court, Lansdown Road, Cheltenham, Glos, > GL50 > > 2JA. Registered in England. 5043538. VAT Number - 728778184 > > ____________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > -- > > //www.freelists.org/webpage/oracle-l > > > > > > > > > -- > http://www.ardentperf.com > +1 312-725-9249 > > Jeremy Schneider > Chicago > -- > //www.freelists.org/webpage/oracle-l > > > > > -- > //www.freelists.org/webpage/oracle-l > > >