sir

I facing problem kindly solve this one :-
The new storage is visible in the database servers and we are able to list the raw devices at the OS level as :

/dev/mapper/mpathn

We have changed the ownership of these disks and given oracle user their ownership (Oracle is a OS user with oinstall group associated with it). We have also given read/write permission to user and group for the device. Please find an example for reference below:

Chown oracleinstall /dev/mapper/mpath4
Chmod 660 /dev/mapper/mpath4
Chown oracleinstall /dev/mapper/mpath5
Chmod 660 /dev/mapper/mpath6
Chown oracleinstall /dev/mapper/mpath6
Chmod 660 /dev/mapper/mpath6
Chown oracleinstall /dev/mapper/mpath8
Chmod 660 /dev/mapper/mpath8
Chown oracleinstall /dev/mapper/mpath9
Chmod 660 /dev/mapper/mpath9

ISSUE: We have observed that once we restart the Server , the ownerships and permissions are wiped out and devices permissions revert back to original root:disk. Due to this oracle software does not works properly as it is installed using oracle install user/group.

That's weird.

Are you using raw disk space as database storage, or files?

yes we are using raw disk space as database storage, the RAW device are mentioned the below

/dev/mapper/mpath4
/dev/mapper/mpath5
/dev/mapper/mpath6
/dev/mapper/mpath8
/dev/mapper/mpath9

Well, I don't know if it has anything to do with your problem, but I generally do not recommend that setup unless you have some (usually) very expensive live backup software.

Otherwise, you can just shutdown ORACLE with a script, back up all the regular files, then start it back up in the middle of the night. That worked fine for most of the companies I worked for and they were all Fortune 500 companies. You may take a slight performance hit, but it seems to be worth it unless you really need 24/7 availability.

Still don't know why permissions would just change out of the blue on your disks. Maybe you should look into ACLs?

Are you using Solaris? Have you tried looking at the permissions of the /dev/rdsk and/or /dev/dsk permissions like c0t0d0s0 etc.?

We are using RHEL 5.4 ENTERPRISE 64BIT

Hi there, why do you want oracle to own the actual disks? The raw devices should belong to root, which is why it changes back on startup. Oracle needs permission to access oracle owned files on these disks (rwx). Just make sure you chmod 661 instead of 660 so you can execute and see the full path. I'm not sure how your security posture is, but putting oracle in the sudoers file will allow you to install patches and scripts at a higher level if need be, but is not always allowed in organizations.

I am with the others in not understanding why oracle would need to own the partitions/drives. For the companies I have worked on, oracle owns the directories/files related to the Oracle install.

Let me explain...

There are two ways ORACLE can save database data. One is by having ordinary files on ordinary host filesystems, or it can take entire raw partitions of disks or whole disks and control them itself and save its data to the drives using its own proprietary drive controllers.

It appears the OP wants to do the second method. I'm not a DBA but I've been a Solaris administrator working in tandem with ORACLE DBAs and we always came to the conclusion that files were better. They might be a bit slower, but it's a lot easier to recover from a crashed disk or something.

I realize what you're saying, but unless he's building this at his house for fun, I find it hard to believe a Linux (Red Hat) administration would be ok with that. Admins control the structure and let DBA's run Oracle on it... Also, dev/mapper/ is a LVM logical volume, which you are attempting to use. LVM's should certainly follow the file structure UGO permissions, opposed to Oracle owning the LVM.When you created your PV, VG, and LV, you would have done it as a privileged user, because a standard user cannot create LVM's. I'm guessing this is why a reboot reverts back to root. You can edit the etc/fstab, but I highly recommend not having oracle own the LVM.