RE: High Availability Options
- From: D'Hooge Freek <Freek.DHooge@xxxxxxxxx>
- To: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- Date: Thu, 28 Oct 2010 17:22:29 +0200
Jeremy
Did not think of that, but as asm has no datafiles it indeed needs to save all
information in the disk header itself. And it is probably useless to store the
name and path of the device in the header of that device.
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
-----Original Message-----
From: Jeremy Schneider [mailto:jeremy.schneider@xxxxxxxxxxxxxx]
Sent: donderdag 28 oktober 2010 16:55
To: D'Hooge Freek
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
Other related posts:
