Re: Oracle on raw devices in SLES9

Michael, Thanks for your reply.

Your given solution worked for me. Thank you once again.

I always thought that i need to touch multipath only when if i have 
multiple paths to a LUN. But in my case , i don't have multiple paths, 
so i thought multipath is not the way to go. But, today i learned that 
it can also used for persistent binding.

But, still i have one more problem with SAN attached disks.

I am creating oracle database on raw in two ways

(1) LVM on a LUN
(2) Physical partitions on a LUN.

i am successful at (2) but not (1)

In (2), i have partitioned the LUN into several partitions , and added 
that LUN into multipath.conf, and added all those /dev/mapper/*  
partitions to my /etc/raw , and installed oracle database, and it 
worked, it installed successfully.

Now , In (1) , Created several LVs on a LUN, added that LUN to 
multupath.conf, configured lvm.conf to bring LVM under the control of 
multipath, and added all /dev/mapper/LV* in /etc/raw , and tried to 
installed oracle database, but it failed. In the "dbca", "step 10 of 
11", "storage section" , it throws an error saying that "Raw device 
validation check for data file /dev/raw/raw1" failed, file /dev/raw/raw1 
is not a raw device . "Device or resource busy" .

Here, anyone, please tell me, RAW-Linux LVM-Multipath  is actually 
supported?

Any help here ?

But, i can tell one thing, in (1) , without multipath , and by giving 
all /dev/volume_group/LV* to /etc/raw , it works , and  it worked for me.

-- Shashi



Michael Kershaw wrote:
> First off, I would never listen to anything REDHAT has to say about
> anything...seriously...maybe just my personal opinion, but it comes
> from a lot of experience between the two big commercial players out
> there...ok..with that said, I have multiple Sles9 Sp3, 10g clusters
> running at the moment.  Some 2 node clusters,  all the way up to
> multiple 18 node clusters in production.  They all utilize shared
> fiber storage, and raw devices with ASM.  I use the device-mapper for
> my persistent binding, and udev for the persistent permissions.  I've
> created a multipath.conf file aliasing my devices to the UID of each
> of the multipath'd luns.  Here's an entry for an individual lun:
>
> multipath {
>                wwid                    1HITACHI_R450A82C09A5
>                alias                     ora_registry1
>                path_grouping_policy    multibus
>                path_checker            readsector0
>                path_selector           "round-robin 0"
>                failback                60
> }
>
> and then make entries in my /etc/raw file like so:
>
> ##
> # First 5 devices for Oracle services
> ##
> raw1:mapper/ora_voting1p1
> raw2:mapper/ora_voting2p1
> raw3:mapper/ora_voting3p1
> raw4:mapper/ora_registry1p1
> raw5:mapper/ora_registry2p1
>
>
> The p1 obviously is the partition for the device of the alias created.
> I simply lay out a partition on each of the luns before I pull them
> into the device-mapper for consistency, and that way anyone else in my
> team can easily see what devices are free on the system in question if
> there is no partition on said device when they're looking.  From the
> /etc/raw file, I just have my entries for permissions in
> /etc/udev/udev.permissions and away we go.  I've had our larger
> clusters running in this fashion for well over a year now.  If you
> have any more questions on anything more specific, or If I've confused
> you even more, just let me know and I can get into more detail.
>
>
> Hope this helps,
> Mike
>
>
>
>
>
> On 6/2/07, Shashi Kanth Boddula <[email protected]> wrote:
>> Ok , the problem "persistence ownership" on raw volumes is over by using
>> udev, now i am facing a one more problem in SLES9 SP3, and the problem
>> is with SAN disks (raw disks) (persistent binding).
>>
>> I am trying to solve the problem by using same udev concept, as i found
>> that we need add line in the udev rules file, and redhat documentation
>> said that we need add a line in /etc/udev/rules.d/20-names.rules file.
>>
>> http://kbase.redhat.com/faq/FAQ_85_8082.shtm
>>
>> (KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="UUID",
>> NAME="devicenam
>>
>> As SLES9 ships a single udev rules file, i have added the above line in
>> /etc/udev/udev.rules in SLES9.
>>
>>
>> KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id",
>> RESULT="3600508b4001007d000017000044a0000", NAME="disk/fc/fc_lun0"
>>
>> For each LUN, i have added a line like above.
>>
>> Now in the YaST, when i run (#yast2 disk) , in the YaST GUI, i am seeing
>> all my assigned names.
>>
>> /dev/disk/fc/fc_lun0
>>
>> /dev/disk/fc/fc_lun2
>>
>> /dev/disk/fc/fc_lun3
>>
>> so on..................
>>
>>
>> But in any LUN, if i try to create a partition, YaST doesn't through any
>> error, but actually the partition will not be created.
>>
>> when you run YaST next time, that partitions own't be there .
>>
>> Any one has any solution for this?
>>
>> How others are doing ?
>>
>>
>> Thanks
>>
>>
>>
>> Alexei_Roudnev wrote:
>> > If you use standard SuSe orarun, then oracle get a secondary group 
>> 'disk'
>> > and have read/write access to the raw devices by default. It works for
>> > everything except CSSFile on CRS (RAC cluster).
>> >
>> > Other method is, yes, to modify udev permissions.
>> >
>> > But I use modified rawnames script which
>> > - creates symlinks for raw devices so that oracle dont work with 
>> 'raw' names
>> > but works with names such as 'DISK1', 'LOG2' and so on;
>> > - it uses 'sleep 5; chown' so it set up owner after udev finish t's 
>> work.
>> >
>> >
>> >
>> > ----- Original Message -----
>> > From: "Kevin Lyons" <[email protected]>
>> > To: "Shashi Kanth Boddula" <[email protected]>
>> > Cc: <[email protected]>; <[email protected]>
>> > Sent: Friday, June 01, 2007 9:36 AM
>> > Subject: Re: [suse-oracle] Oracle on raw devices in SLES9
>> >
>> >
>> >
>> >> On Fri, 2007-06-01 at 21:37 +0530, Shashi Kanth Boddula wrote:
>> >>
>> >>> Hi All,
>> >>>
>> >>> I am installing Oracle 10gR2 on SLES9 SP3 raw volumes which is 
>> made by
>> >>> Linux LVM. As per the oracle documentation, all the raw devices 
>> should
>> >>> be owned by oracle user, for that we need to change the ownership 
>> on all
>> >>> raw devices  where your installing database to oracle user.
>> >>>
>> >>> The problem is , after you create a mapping file in /etc/raw, and 
>> when
>> >>> you start the raw service (#rcraw start), the permission again 
>> set back
>> >>> to root.
>> >>>
>> >>> I have tried to solve this problem by modifying /etc/init.d/raw 
>> file ,
>> >>> but still , always , when you start the raw services, the 
>> ownership on
>> >>> raw devices again go back to root.
>> >>>
>> >>> Anyone has any solution for this ?
>> >>>
>> >>>
>> >> Modifying the /etc/init.d/raw script is not the way to go.
>> >>
>> >> When the raw devices (or really any devices) are created, the udev
>> >> subsystem automatically sets the permissions to root:disk:660.
>> >>
>> >> On SLES9 edit the /etc/udev/udev.permissions file which has rules for
>> >> what permissions are given to devices files as they are created.
>> >>
>> >> For raw devices, the permissions are set by the following line:
>> >>
>> >> raw/raw*:root:disk:660
>> >>
>> >> You want to add some rules to set the permissions for the raw devices
>> >> that you are going to use like so:
>> >>
>> >> raw/raw1:oracle:oinstall:644
>> >> raw/raw2:oracle:oinstall:644
>> >> raw/raw3:oracle:oinstall:644
>> >> raw/raw*:root:disk:660
>> >>
>> >> Or whatever is appropriate for your setup.  The rules can contain 
>> some
>> >>
>> > standard
>> >
>> >> shell expansions like 'raw/raw[1-3]' or similar.  The man page has 
>> more
>> >>
>> > details.
>> >
>> >> Note that the file is processed in order, and when a matching rule is
>> >>
>> > found
>> >
>> >> processing stops.  So you need to have the default rule come after 
>> your
>> >>
>> > custom
>> >
>> >> rules or it will not work.
>> >>
>> >> Thanks,
>> >> Kevin
>> >>
>> >>
>> >>
>> >> --
>> >> To unsubscribe, email: [email protected]
>> >> For additional commands, email: [email protected]
>> >> Please see http://www.suse.com/oracle/ before posting
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> -- 
>> To unsubscribe, email: [email protected]
>> For additional commands, email: [email protected]
>> Please see http://www.suse.com/oracle/ before posting
>>
>>


-- 
To unsubscribe, email: [email protected]
For additional commands, email: [email protected]
Please see http://www.suse.com/oracle/ before posting