RE: High Availability Options
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxx>
- To: "jeremy.schneider@xxxxxxxxxxxxxx" <jeremy.schneider@xxxxxxxxxxxxxx>, "Freek.DHooge@xxxxxxxxx" <Freek.DHooge@xxxxxxxxx>
- Date: Thu, 28 Oct 2010 11:24:07 -0400
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
Other related posts:
