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