RE: High Availability Options
- From: "Amaral, Rui" <Rui.Amaral@xxxxxxxxxxxxxxxx>
- To: "'Paul.McManus@xxxxxxxxxxxx'" <Paul.McManus@xxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 28 Oct 2010 10:19:00 -0400
those are the two options that Oracle is recommending because they simplify the
process for admins.
If multipath then you can use the /dev/mapper/mpath* since they are persistent.
They are grouped by WWID and the bindings file so those "should" not change.
The ones in /dev/dm-* usually do so never use those. You can also use
/dev/disk/by-id/* as well since those are also persistent based on the the WWID
of the luns. Both of those require a script to change the permissions on boot
but that is easy enough to do. I am sure there are a couple of other ways but
those are two that I normally use. I used the following as a reference for it
(it's RedHat since those are systems that I am mainly focused on but I am sure
other distros have similar things):
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html
Rui Amaral
Database Administrator
ITS - SSG
TD Bank Financial Group
220 Bay St., 11th Floor
Toronto, ON, CA, M5K1A2
(bb) (647) 204-9106
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Paul McManus
Sent: Thursday, October 28, 2010 10:01 AM
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
______________________________________________________________________
NOTICE: Confidential message which may be privileged. Unauthorized
use/disclosure prohibited. If received in error, go to www.td.com/legal for
instructions.
AVIS : Message confidentiel dont le contenu peut être privilégié.
Utilisation/divulgation interdites sans permission. Si reçu par erreur, allez
au www.td.com/francais/avis_juridique pour des instructions.
Other related posts:
