Re: High Availability Options
Date: Thu, 28 Oct 2010 10:54:40 -0400
Message-ID: <AANLkTik627Rtny=XH9b6aCXeUJ=Eh-nEd5g=6aocTL4+_at_mail.gmail.com>
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_at_uptime.be> 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_at_uptime.be
> tel +32(0)3 451 23 82
> http://www.uptime.be
> disclaimer: www.uptime.be/disclaimer
> ________________________________________
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Paul McManus
> Sent: donderdag 28 oktober 2010 16:01
> To: oracle-l_at_freelists.org
> 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
> ______________________________________________________________________
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.ardentperf.com +1 312-725-9249 Jeremy Schneider Chicago -- http://www.freelists.org/webpage/oracle-lReceived on Thu Oct 28 2010 - 09:54:40 CDT