Re: High Availability Options

From: John Thompson <jhthomp_at_gmail.com>
Date: Thu, 28 Oct 2010 10:37:10 -0500
Message-ID: <AANLkTi=jo3uR4KAznHgJCnTkQ=Spgv+t3VT+fhTt9FXp_at_mail.gmail.com>

I've been using ASMLIB for going on 2 yrs now in production on 22 servers without any issues. We use EMC Powerpath which ensures the names are correct on reboots.

On Thu, Oct 28, 2010 at 10:24 AM, Bobak, Mark <Mark.Bobak_at_proquest.com>wrote:

> 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Jeremy Schneider
> Sent: Thursday, October 28, 2010 10:55 AM
> To: Freek.DHooge_at_uptime.be
> Cc: Paul.McManus_at_maxima.co.uk; oracle-l_at_freelists.org
> 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_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-l
>
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Oct 28 2010 - 10:37:10 CDT