Re: High Availability Options

  • From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
  • To: Freek.DHooge@xxxxxxxxx
  • Date: Thu, 28 Oct 2010 10:54:40 -0400

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


Other related posts: